fix(bigint): throw error when casting BigInt that's outside of the bounds of what MongoDB can safely store

[vkarpov15]

Fix #15200

Summary

MongoDB stores BigInts as Longs under the hood, so you may lose precision if storing a BigInt that's too large in MongoDB. This PR makes Mongoose throw an error in that case, to avoid accidentally overwriting valid data.

Without useBigInt64, MongoDB can only store the range of a signed 64 bit integer, which is what this check uses. With useBigInt64, you can actually store up to the max unsigned 64 bit integer (18446744073709551615), but that leads to some unexpected quirks with querying. For example, the following $gt query doesn't return any docs even though 18446744073709551615n > 9223372036854775807n.

'use strict';

const mongoose = require('mongoose');
mongoose.set('debug', true);

(async function() {
  await mongoose.connect('mongodb://127.0.0.1:27017/mongoose_test', { useBigInt64: true });

  const schema = new mongoose.Schema({
    myBigInt: BigInt
  });
  const Test = mongoose.model('Test', schema);
  await Test.deleteMany({});

  const { _id } = await Test.create({ myBigInt: 18446744073709551614n });
  const doc = await Test.findById(_id);
  console.log('From db', doc);
  //doc.markModified('myBigInt');
  doc.myBigInt = 18446744073709551615n;
  await doc.save();

  console.log(await Test.findById(_id));
  console.log(await Test.findOne({ myBigInt: { $gt: 9223372036854775807n } })); // null
})();

Although this is more of a bug fix than anything, I think postponing it to a smaller minor release is prudent just in case.

Examples

[hasezoey]

Looks good to me, though tests for this new validation error would be great.
Also consider using constants (or at least add a comment) to explain those "magic numbers" at a glance.