Fix document field generation for vnd_cbor and vnd_smile

[pgomulka]

there is a special case for creating expected value for Floats when
xcontentType is CBOR or SMILE

closes #67009
closes #67018

• Have you signed the contributor license agreement?
• Have you followed the contributor guidelines?
• If submitting code, have you built your formula locally prior to submission with gradle check?
• If submitting code, is your pull request against master? Unless there is a good reason otherwise, we prefer pull requests against master and will backport as needed.
• If submitting code, have you checked that your submission is for an OS and architecture that we support?
• If you are submitting this code for a class then read our policy for that.

[elasticmachine]

Pinging @elastic/es-core-infra (Team:Core/Infra)

[DaveCTurner]

Would you unmute the test I muted too? See a0c090a.

[dakrone]

LGTM (with un-muting comment as David mentioned)

[DaveCTurner]

LGTM2 (empirically at least, I've no idea why this fixes anything but can confirm that it does)

[pgomulka]

@DaveCTurner
the problem was with random test data generation. Looks like there is a special logic to handle Float data types for cbor and smile. Previously we only had one XcontentType (i.e. XContentType.CBOR) per each XContent (i.e. CborXContent)
Now we also have versioned XContentTypes (think of this as an allowed media type) like VND_CBOR - application/vnd.elasticsearch+cbor. This also uses CborXContent so should be included into this conditional test data generation logic.
Let me know if this clarifies a little