chore: Expose feature flags for bson3

[joshuamegnauth54]

The bson crate supports useful helper APIs for chrono, jiff, and other crates. These feature flags aren't exposed through this crate even though it re-exports bson. This commit simply exposes those features for users so that they don't have to depend on bson directly.

This is useful for a few reasons. The first is that depending on a separate copy of bson will likely bring in a version different than that of the mongodb crate. The different types can conflict as mongodb::bson::Bson is different from bson::Bson.

The second reason is that two copies of the same crate leads to binary bloat. It's likely that tree shaking can't remove either copy because the re-exported bson is used within the mongodb crate. Both crates, as well the transitive dependencies that differ, will be included in the crate graph.

The third reason is that it's simply more ergonomic to have these features exposed through mongodb too rather than including a separate crate.

[isabelatkinson]

Hi @joshuamegnauth54, I discussed this with the team and we would prefer not to add these feature flags. We previously exposed bson feature flags through the driver, but decided to remove them in the most recent major version release to reduce duplication across the libraries.

depending on a separate copy of bson will likely bring in a version different than that of the mongodb crate.

Is this something you've see in practice? The dependency resolver should select a single version of bson as long as the version in your Cargo.toml and the version used by the driver are semver-compatible. If so, can you let us know which specific versions of bson and the driver are causing this problem?