fix(NODE-5546): decimal 128 fromString performs inexact rounding

[W-A-James]

Description

What is changing?

• Corrected Decimal128.fromString algorithm to match that in mongo-c-driver
• Unskipped Decimal128 spec tests
• Update Decimal128 spec tests

Is there new documentation needed for these changes?

• No

What is the motivation for this change?

NODE-5546

Release Highlight

Decimal128 constructor now throws when detecting loss of precision

Prior to this release, Decimal128 would round numbers with more than 34 significant digits and lose precision. Now, on detecting loss of precision, Decimal128's constructor and Decimal128.fromString will throw a BSONError. This behaviour should have been the default as the Decimal128 class was always intended to be high-precision floating point value. As such, silently rounding is undesirable behaviour.

// previous behaviour
> new Decimal128('10000000000000000000000000000000001')
new Decimal128("1.000000000000000000000000000000000E+34")

// new behaviour
> new Decimal128('10000000000000000000000000000000001')
Uncaught:
BSONError: "10000000000000000000000000000000001" is not a valid Decimal128 string - inexact rounding
    at invalidErr (/home/wajames/js-bson/lib/bson.cjs:1402:11)
    at Decimal128.fromString (/home/wajames/js-bson/lib/bson.cjs:1555:21)
    at new Decimal128 (/home/wajames/js-bson/lib/bson.cjs:1411:37)

Double check the following

• Ran npm run check:lint script
• Self-review completed using the steps outlined here
• PR title follows the correct format: type(NODE-xxxx)[!]: description
  • Example: feat(NODE-1234)!: rewriting everything in coffeescript
• Changes are covered by tests
• New TODOs have a related JIRA ticket

[nbbeeken]

🎵 I saw the sign
And it opened up my eyes, I saw the sign
Life is demanding without understanding 🎵

[nbbeeken]

Check this with a test case

[W-A-James]

Looking at it, firstDigit is always 0; it doesn't change at all throughout the entire function, so I'm going to go ahead and remove all references to it.

With regards to changing to the gte sign, the cases that trigger this branch are clamped zeros with large positive increments (see spec tests in decimal128-1.json), but any number with a sufficiently large exponent can enter this block.

If we consider a number like 1000000000000000000000000000000000e6112, which has 1 significant digit, 34 digits before the exponent and an exponent that's above max exponent, then what happens when we have a gt sign here is that we end up with the following result:

> Decimal128.fromString('1000000000000000000000000000000000e6112')
new Decimal128("0E+6111")

since we skip the iteration when lastDigit reaches MAX_DIGITS and proceed without error despite the fact that we should have overflowed. This leads us to get to our encoding and produce the incorrect result we see above.

With the gte sign in place, we get the following result, which is what we expect

> Decimal128.fromString('1000000000000000000000000000000000e6112')
Uncaught:
BSONError: "1000000000000000000000000000000000e6112" is not a valid Decimal128 string - overflow
    at invalidErr (/home/wajames/js-bson/lib/bson.cjs:1402:11)
    at Decimal128.fromString (/home/wajames/js-bson/lib/bson.cjs:1540:17)

it seems like we should have spec test that test corner cases like this.