SERVER-95889 Make FLE2IndexedEqualityEncryptedValueV2 wrap mc_FLE2IndexedEncryptedValueV2_t

[marksg07]

Main repo PR: https://github.com/10gen/mongo/pull/29265

• Moves structs needed by fle_crypto to headers
• Adds validation functions for mc_FLE2IndexedEncryptedValueV2_t and mc_FLE2TagAndEncryptedMetadataBlock_t which are needed by fle_crypto

[sgolemon-corp]

I think you're going to find that even these names are too generic given how C ODRs its enums into the global symbol space. It wasn't a problem when these were scoped to a single TU, but now that they're in a header, we should give them more distinctness.

e.g.

typedef enum {
  kFLE2IEVTypeInitV2,
  kFLE2IEVTypeEqualityV2,
  kFLE2IEVTypeRangeV2,
};

[marksg07]

Changed

[sgolemon-corp]

This function seems.... sus.

You seem to just be checking if the value is in the explicit list of named numeric values.

Thing is that's not very meaningful in terms of if a type is "valid" or not.

(MAXKEY, MINKEY] (the set of 128 values from 0x80..0xFF) are all "valid" as BSON types, for example. Those two constants define the endpoints of the "User Defined BSONElements" range.

On the other side, EOD and UNDEFINED don't make sense as valid encodable types. (Though "Undefined" is defined, it's just no longer a valid type, so that one gets.... complicated).

TL;DR - The only truly "invalid" type is EOD.

Unless I'm misunderstanding the purpose of this method, I'd probably just reduce it to:

return bson_type != BSON_TYPE_EOD;

Further Reading: https://bsonspec.org/spec.html

[joshbsiegel]

I went ahead and modified this in order to get a test passing, feel free to change it back if necessary.

[marksg07]

Huh, I didn't realize that [MAXKEY, MINKEY] are valid, I was wondering what those meant. Thanks for the clarification.

[kevinAlbs]

LGTM with minor comments.