MONGOCRYPT-922 Make padding strings unique

[kevinAlbs]

Summary

Make padding strings unique.

Background & Motivation

See report in MONGOCRYPT-913 for details. This addresses finding with ID 1.

Quoting https://docs.google.com/document/d/1KhCFiofunsk7VeVB4VftvxFd9rQQOZrBQaTqHCljHtU/edit?tab=t.0:

appended with a 0xFF byte, which makes it an invalid UTF-8 sequence

This PR proposes appending a four byte counter after the 0xFF to ensure all padding strings are unique.

Testing

Appending an additional four bytes resulted in needing to extend the test data in RNG_DATA.h in substring tests to avoid the error "Out of random data".

To additionally verify changes, the QE Text driver spec and prose tests were run locally with the C driver. The only necessary changes in tests were to update the exoected __safeContent__ (which I expect is a direct result of updating the padding string contents).

[erwee]

Discussed this with the crypto team. We'll be disputing the finding that an adversary can tell the real affix length after the document has been inserted (They shouldn't because each of the "fake" padding tokens have already been mapped to unique safeContent tags). So I don't think this change will be needed (perhaps not yet).

[kevinAlbs]

adversary can tell the real affix length

Does QE Text intend to protect against an adversary intercepting traffic to the server? I expect "yes". And the FLE2InsertUpdatePayloadV2 sent from the client could be decoded to get the insert length. See decode_length.py for an example printing the length by decoding the old insert-prefix.json payload.

[erwee]

I realize this change would also require a server-side change because the server depends on the padding tokens being identical and being adjacent to each other. Besides that, it would also prompt a change in the OST paper to account for the extra counter bytes to disambiguate the padding strings. As for this latter point, I'll have to discuss with Seny & Tarik first.