Speed up calculation of example groups used by the mutator

[Zalathar]

My profiling of #2308 found that Hypothesis currently spends a lot of time generating the example groupings that the mutator uses to insert duplicate values.

I found that by switching to a dedicated @calculated_example_property implementation, I could speed up those calculations by a decent amount.

In my informal testing, this cuts about 10 seconds out of a 50 second test run, which is a nice improvement.

[Zalathar]

The first two commits are just preliminary refactoring; all of the interesting changes are in the third commit (Speed up calculation...).

[Zalathar]

Looks like there's some sort of subtle interaction with test_text_containment[1] in the quality suite.

I'll have to investigate whether this is a real problem, or some quirk of the test itself.

[DRMacIver]

Thanks for continuing to look into this!

[DRMacIver]

Looks like there's some sort of subtle interaction with test_text_containment[1] in the quality suite.

I'll have to investigate whether this is a real problem, or some quirk of the test itself.

Oops, I missed this when I approved. I still think the change looks good. Let me know if you want me to rereview when you've fixed this.

[Zalathar]

The bad news is that something cursed is happening in the test suite on Python 3.5.

The good news is that it's consistent (and locally reproducible via build.sh), so at least I can investigate it.

https://dev.azure.com/HypothesisWorks/Hypothesis/_build/results?buildId=3649&view=logs&j=bf737dbf-2401-5929-1d68-053a1a5f2d7c&t=aa278db6-67f9-574a-fa2c-7dd4d540935b

[Zac-HD]

I'd be OK with just dropping support for Python 3.5 as soon as keeping it is causing noticably more work. It's ~3% of our downloads, no longer supported by Numpy et al, and pretty close to EOL (September) anyway. I think @DRMacIver feels the same way?

[Zalathar]

For what it's worth I don't think 3.5 is actually at fault here; this is probably just a deterministically-flaky test that happens to get unlucky on 3.5 after these changes.

[Zalathar]

Yeah, I'm pretty sure the underlying test (#2322) is theoretically flaky, which normally isn't noticeable because it uses derandomize=True under the hood. So it consistently passes or fails at any point, but unrelated changes can make it suddenly break on a particular platform/version.

For the purposes of this PR I've worked around the problem by just increasing max_examples for that particular test, so it's much harder to get unlucky enough to actually fail.

[Zalathar]

Oh, it was already fixed by 2fc4a55, so I can just rebase.

[DRMacIver]

I'd be OK with just dropping support for Python 3.5 as soon as keeping it is causing noticably more work. It's ~3% of our downloads, no longer supported by Numpy et al, and pretty close to EOL (September) anyway. I think @DRMacIver feels the same way?

I'd be pretty OK with dropping it from our CI and putting it in a "Still technically supported but we're offloading testing to our users" state until EOL and then formally dropping it in September. I don't mind formally dropping it sooner than that but I think I'd need a reasonably convincing reason.

[Zac-HD]

I don't see any real benefit in dropping 3.5 without also doing the code cleanups that will enable, so let's just keep it - and keep all two CI jobs testing it - until EOL.