While trying to add stricter validation to the [BSONElement constructor that uses the TrustedInitTag|https://github.com/10gen/mongo/blob/master/src/mongo/bson/bsonelement.h#L876-L881
] in SERVER-104392, we figured that some of the existing call sites were passing in a wrong fieldNameSize.

The contract for creating a BSONElement requires that the fieldNameSize must be 0 for any EOO BSONElement, and otherwise equal the length of the field name string *plus* the NUL-terminator.

When adding invariant checks to the BSONElement TrustedInitTag constructor that actually validate the passed fieldNameSize value, we found that the passed fieldNameSize value was not always correct from several occurrences in the BSONColumn code, e.g. here, here, here

Most of the places in the BSONColumn code use the BSONElement type as an accessor to a byte sequence after checking that the next byte is a "control byte" via this function. This function returns true for an EOO byte as well as certain other bytes, but the code following it makes no such distinction, e.g.

    uint8_t control = *buffer;
    if (bsoncolumn::isUncompressedLiteralControlByte(control)) {
        BSONElement literalElem(buffer, 1, BSONElement::TrustedInitTag{});
...

The above would violate the BSONElement TrustedInitTag contract if control points to an EOO byte. In this case, the BSONElement should be created with a fieldNameSize of 0 instead.

Note that our existing code works correctly if we do not add further validation to the BSONElement TrustedInitTag constructor, as we are not using the BSONElement objects created at these call sites for much. Especially, we are not calling ready their fieldNameSize() methods or are dereferencing invalid memory.

However, it is still a misuse of the BSONElement type, and we should consider changing these call sites to not use BSONElement to point to arbitrary memory sequences, but rather use some other type that does not have such implicit invariants about the struct's internals as BSONElement has.