[tonyandrewmeyer]

This adds a Hypothesis property test suite in test/property/ on the long-lived property-tests branch, with a short run on every PR to that branch and a much longer one every night. The first properties cover the glue between Scenario and ops: _EntityStatus round-tripping through _to_ops() and from_ops() with arbitrary messages, an unknown status dropping its message on the way (the one status that doesn't round-trip), and TCPPort, UDPPort and ICMPPort accepting exactly the port numbers they should, with the edges of the range pinned with @example.

• Hypothesis is in a new property dependency group (it also brings in sortedcontainers), and only the new tox -e property environment and lint install it. The unit environment doesn't, and the unit and coverage runs ignore test/property/.
• Settings profiles in test/property/conftest.py, picked with HYPOTHESIS_PROFILE, decide how hard each run looks: ci is derandomised so a PR's result doesn't depend on luck, and nightly is 10,000 examples with fresh randomness. The tests themselves don't set max_examples.
• property-tests.yaml runs the ci profile on PRs and pushes to property-tests. GitHub only schedules workflows from the default branch, so the nightly run is a separate workflow on main, in ci: run the property-tests branch's property tests nightly #2897. It checks this branch out, merges in the current main so that it tests today's ops, and a scheduled failure opens an issue through notify-scheduled-failure.yaml, like the other scheduled workflows.
• CONTRIBUTING.md says how to run them, that property test PRs go against property-tests, and that a counterexample the nightly run finds should be fixed on main and then pinned with @example(...) here.

The aim is to have a lot more property tests than these over time. They live on a branch rather than main for now (as Pebble's do), which keeps the new dependency and the review load of a lot of generated tests off main while we find out how much they catch. main is merged into the branch regularly, and fixes for anything the tests find go to main.

[benhoyt]

I'm good with the idea and running a short version on PR (longer on nightly schedule), however, I'm pretty uncertain about adding these to the main branch (I see your comment in the PR body -- thanks). My concerns:

• The new dependency in main (and its sub-dependencies) -- thinking of distros and package registries.
• I think for this to be effective we'll want to be adding quite a few test cases, which will be a lot of code to review and so on. I think if we put it on a "basically AI-managed branch" (or fork) we can do a lot more lightly-reviewed spraying, and just push (unit) test cases and fixes to main when it finds an issue.

Additionally, the specific examples here, the Status and Port (data) classes, don't sell it for me. Aren't they basically testing that the dataclass initialisers work? An example that's actually doing significant work would be more interesting -- for example, parsing multipart bodies in pebble.py or similar.

Perhaps worth further discuss in our 1:1 tomorrow (or as a team if needed).