Add BSON Binary Subtype 9 support for vector storage and retrieval.

[vbabanin]

Description

This PR introduces the implementation of BSON Binary Subtype 9 - Vector, based on the proposed specification for efficiently storing and retrieving densely packed arrays of numbers.

Key Changes:

BSON Binary subtype: Implements a new BSON binary subtype (value "\x09") for vectors to better manage dense numeric arrays.

API enhancements:
Updates include idiomatic APIs that facilitate the translation between arrays of numbers and their BSON binary representations.

Data type support: Supports various data types (dtypes), including INT8, FLOAT32, and PACKED_BIT.

Implementation details

Encoding and decoding: Adds methods to encode and decode vectors according to the specified dtype and padding.

Draft status and review:

The specification this PR depends on is under review. You can review the specification here: BSON Binary Subtype 9 Specification PR. Substantial changes to the specification are not expected, therefore your feedback on this preliminary implementation would be valuable.

JAVA-5544

[jyemin]

Just giving this an initial review as part of my review of the spec.

[vbabanin]

Notice that the tests directly send a Vector object rather than wrapping it in Binary due to a codec that transforms Vector to Binary. However, during retrieval, BinaryCodec is activated, resulting in a Document that contains Binary instead of Vector. This inconsistency arises because BsonTypeClassMap maps BsonType.BINARY to Binary.class, but does not account for Binary subtypes similarly.

To ensure consistency between write and read operations, we could modify ContainerCodecHelper to prioritize the VectorCodec during decoding, akin to our handling of the UUID subtype when the representation is not UNSPECIFIED. See the implementation here: ContainerCodecHelper.

However, this enforcement could still result in inconsistencies. For example, if a user initially writes a Vector wrapped in Binary, it would not be decoded back as Binary, but as Vector. This creates a reverse inconsistency from the current scenario where Vector is automatically converted to Binary.

We have several options:

• Retain the current behavior without any changes.
  Vector -> raw binary
  raw binary - > Binary
• Enforce decoding to Vector if subtype is 9 (vector) in ContainerCodecHelper.
  Vector -> raw binary
  raw binary -> Vector
• Make the behavior of VectorCodec configurable via the constructor, allowing users to determine the behaviour they want. This would necessitate detailed documentation to assist in discovery and understanding.

I suggest we maintain the existing functionality for now. If this becomes an issue for users, we can reevaluate.

UPD: I suggest we enforce decoding to Vector if the subtype is 9 (vector) in ContainerCodecHelper, similar to how we handle the UUID subtype. This should provide a better user experience. I have updated ContainerHelper to parse to Vector if there is a VectorCodec available. If a VectorCodec is not present, due to the user explicitly providing a registry without one, we will default to using the BinaryCodec.

Note that when a UUID codec is not present, decoding fails rather than defaulting to Binary. I think we should not let the decoding fail in the case of UUID and Vector codec not being preset and continue decoding to Binary. However, I have not made any changes related to UUID here; we could consider those changes in a separate PR.

[stIncMale]

Note that static checks don't pass. Please make sure there are no new warnings when building the project.