`sets` strategy backtracks more than it needs to

[hgoldstein95]

Correct me if I'm wrong here, but it seems like sets backtracks in a lot of common cases it doesn't need to. The current implementation:

1. Generates a list of the requested size;
2. backtracks if there are duplicates, and then;
3. turns that list into a set.

This means that any time you have duplicates (which could be very often depending on the desired set size and the strategy for contained values) the whole generator gives up. I propose that the better approach would be:

1. Generate a list of the requested size (or greater?);
2. turn that list into a set;
3. check if the set is still an appropriate size.

This would mean that a lot of cases that currently backtrack won't need to, and it also gives us options other than backtracking. E.g., if the resulting set is too large, we could remove some elements, and if it's too small we could add some until we have a big enough set.

Does this make sense? Am I missing something, or would this be a pretty straightforward performance improvement?

[Zac-HD]

It would be a straightforward improvement for speed of generation, but also makes the choice_sequence -> test_case mapping much more complicated, which is bad for mutation. That manifests in (much) worse shrinking behavior, and worse exploration in both blackbox generation (from cloning parts of the choice sequence and other tricks) and greybox generation (hypofuzz).

The "good" news is that much of this problem arises from applying that clone-parts trick, so if can just stop doing that for elements of a unique list per #4458 (comment) I expect a pretty nice improvement.

[hgoldstein95]

I'm not sure I 100% understand the proposed fix, but if you have a solution then I'm happy. I just think we can't really afford for high-traffic, built-in strategies to be discarding all over the place (especially without warning anyone that that's the case).