BSON exported

[kraenhansen]

What, How & Why?

This closes #3242 by exporting the BSON types from both Realm JS and Realm Web.

This is what the JSDocs look like:

☑️ ToDos

• 📝 Changelog entry
• 📝 Compatibility label is updated or copied from previous entry
• 🚦 Tests
• 📝 Public documentation PR created or is not necessary
• 💥 Breaking label has been applied or is not necessary

If this PR adds or changes public API's:

• typescript definitions file is updated
• jsdoc files updated
• Chrome debug API is updated if API is available on React Native

[kraenhansen]

Hah! What a weird change. I didn't move this file 😆

[kneth]

Do we need to check Decimal128 too?

[kraenhansen]

If constructing an ObjectId works, I would expect a failure to construct a Decimal128 to come from a bug in the bson package. In other word, I think its safe to keep it limited to this.

[blagoev]

We are not validating if the BSON type is coming from our dependency or somewhere else. Are we going to do that or we are going to allow external BSON type usage. So two ways to handle these:

1. We allow the usage of external BSON types and its responsibility of the developer to handle any incompatibilities
2. We validate the BSON type is explicitly our own dependency and throw errors if it is not.

Currently we have these checks which will be valid regardless of where the BSON type is coming from.
https://github.com/realm/realm-js/blob/v10/src/node/node_value.hpp#L101-L123

[kraenhansen]

I've rebased this on the current master and testet it locally in Chrome debugging mode ✅

[cristianoccazinsp]

Started to get BSON: For React Native please polyfill crypto.getRandomValues, e.g. using: https://www.npmjs.com/package/react-native-get-random-values. from either this or similar update.

Any thoughts? We send warnings to our reporting tool so this is causing some really bad noise right now.

#3714