`generic` PR followups

[adisos]

items to complete before release:

• [x] new ICMP type not restricted only to RFC combinations
• [x] 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.