[write-fonts] reproduce and fix non deterministic gvar serialization

[anthrotype]

Meant to reproduce the issue discussed at googlefonts/fontc#647

If we are lucky enough the CI should fail, otherwise flip the coin again and you'll see...

[anthrotype]

nice, it did fail the first time :)

https://github.com/googlefonts/fontations/actions/runs/7277928604/job/19831021279?pr=750

assertion `left == right` failed
  left: Some(All)
 right: Some(Some([1, 3]))

[anthrotype]

Finally it took me a few rounds but I managed to also make the CI randomly pass without actually changing anything :)

https://github.com/googlefonts/fontations/actions/runs/7277928604/job/19831276618

[cmyr]

Good find cosimo, and I think that matching the behaviour of fonttools is the right call.

This was interesting, and I'm glad it made me go and look more closely into the rust HashMap implementation. :)

[anthrotype]

This particular test glyph is funny: basically, there are 7 tuple variations, 5 of them have PackedPointNumbers::All, 2 of them have PackedPointNumbers::Some([1, 3]). Using either one as the shared point numbers will save the same number of bytes (4 in this particular case).
Now, because of the indeterminacy of hashmap order (which uses a random hash seed that changes at every execution), we would end up using either one at every execution, leading to a gvar with the same total size but different checksum.
So I decided that between the two possible valid shared point numbers, we should use the first one that fits the bill, following the ordering of the tuple variations themselves, i.e. the set of packed point numbers that first occurs when iterating over the tuple variations.
One could also take the last, and Rust max_by_key does exactly that, but since this whole piece of code was meant to port and match fonttools, I think it made more sense to match Python's max() behavior and take the first in case of ties.

[cmyr]

Oh one other idea here: you should be able to get closer to ensuring that this test fails consistently by just running it in a loop for some number of iterations.

(and another clarification is that (if I'm understanding correctly) the hashmap does not use a new seed on each execution, but each call to HashMap::new() uses a different seed)

[anthrotype]

each call to HashMap::new() uses a different seed

oh good to know.

you should be able to get closer to ensuring that this test fails consistently

good point, but I think now that I fixed it it's no longer going to fail/pass inconsistently so maybe it's not worth doing the loop any more?