Add support for property testing with `proptest`

[bruceg]

This allows for generation of arbitrary data types that contain CIDR types.

[stbuehler]

I'm probably missing quite some context here.

As far as i can tell proptest is (at least partially) about creating "test" values in a structured way.

I somehow doubt that you can derive generating values for the cidr types (and probably others), because they need to maintain certain invariants about the contained data.

Can you explain what you expect the derived implementations to do?

[bruceg]

Fair questions.

1. Arbitrary is a trait in proptest that represent types that can generate "arbitrary" values of themselves. proptest itself is a framework for doing property testing, whereby you can assert certain properties of your types (ex any IPv4 types can be converted to a string and back again into a value that is equal to the original). When doing the testing, it will attempt to probe boundary conditions, will try to reduce failures to the simplest data that triggers the issue ("shrinking") and will record failures to files to ensure those particular cases are retested. If this interests you, I can add some unit tests to this PR using proptest.
2. That is a good point. The masks in CIDR types, at minimum, will have a smaller range than their underlying type and so the automatically derived Arbitrary will produce bogus values. I will write a manual implementation for those and check the other types for similar invariants.
3. I am using the types in this crate in other structures that I want to property test. I can write manual implementations, but it gets super awkward with some types that I neither have access to the internals nor can implement external traits for.

[stbuehler]

Closing for now.

Proper support needs a manual strategy:

• https://docs.rs/proptest/latest/proptest/strategy/trait.Strategy.html#tymethod.new_tree
• https://docs.rs/proptest/latest/proptest/strategy/trait.ValueTree.html

The "ValueTree" seems to represent one path in a tree of choices to "complicate" (and simplify) a value; so new_tree basically needs to pick a "path" (i.e. address) and a starting point (i.e. a prefix length); complicate and simplify can then walk the path up and down; the current value would be the (masked address) prefix at the current length. This should cover Cidr types (the simplest values being the empty prefix or "any").

For Inet it gets more complicated, as there are two dimensions - simplifiy could mean using a shorter prefix length or using less non-zero bits in the host part.