`generic` PR followups

[adisos]

items to complete before release:

• new ICMP type not restricted only to RFC combinations
• Consider pkg reorg: Should keep both netset.TransportSet and connection.Set ? (also confusing with netset.ConnectionSet) -- remove connection.Set , consider renaming netset.ConnectionSet.

additional items:

• Remove unused code in package netp
• Keep or remove unused rightTripleSet and outerTripleSet?
• Add NumPartitions interface method to TripleSet?
• Validation of types ranges (ports, icmp properties, etc), error handling
• Define type TripleDisjoint for supporting other protocol numbers in connection set?
• Revisit string() functions for the various types in package netset
• More tests for extended connection set
• Document example objects, operations, etc , better documentation for packages , readme with examples , internal representation impact
• type definitions: can LeftTripleSet be defined as type LeftTripleSet[S1 Set[S1], S2 Set[S2], S3 Set[S3]] Product[Product[S1, S2], S3] (instead of new struct with one member)?
• check tests coverage, add relevant tests

[elazarg]

I think we should consider

• making the interval type generic.
• having a dedicated "small set" abstraction, something that fits the protocol type more tightly.

[adisos]

I think we should consider

* [ ]  making the interval type generic.

* [ ]  having a dedicated "small set" abstraction, something that fits the protocol type more tightly.

Thanks @elazarg
Can you elaborate what you meant with having a dedicated "small set" abstraction?

[elazarg]

I mean a set for two values (e.g. for TCP/UDP), or more generally a set for K values, which is more difficult to encode into golang's type system.