GeezerVison

…rmat

DecimalCodec.EncodeDecimal wrote coefficients with more digits than the
format allows, and exponents outside its range, without any check (only a
Debug.Assert). In Release builds the excess bits overflowed into the
combination/exponent fields and the server stored a different value, e.g.:

  12345678901234567890123456789012345 -> DECFLOAT(34) stored 8345678901234567890123456789012345
  30000000000000004E-17               -> DECFLOAT(16) stored 0.08000000000000004
  1E400                               -> DECFLOAT(16) stored 8.000000000000001E-353

The encoder now brings the value into the format's ranges without changing
its numeric value (dropping trailing zeros of the coefficient, folding the
exponent into the coefficient, clamping the exponent of zero), and throws
OverflowException when the value cannot be represented exactly (too many
significant digits, exponent overflow or underflow). Values that previously
got corrupted although representable (e.g. 1E384 in DECFLOAT(16)) now work.

The conversions formatted the value with a fixed custom format and then
removed the decimal point, assuming one was present. This threw
ArgumentOutOfRangeException for every value without a fractional part,
e.g. (FbDecFloat)1m, (FbDecFloat)100m, (FbDecFloat)2.0, and for values
smaller than the format's decimal places, e.g. (FbDecFloat)1e-20. It also
dropped the scale of decimals (1.10m became 1.1) and digits beyond 15
decimal places of doubles (7 for floats).

- decimal: converted exactly from its 96-bit integer and scale, so the
  value and its scale are preserved (1.10m -> 110E-2), including -0.
- double/float: converted to the shortest decimal that round-trips to the
  same binary value ("R" format), e.g. 0.1 -> 1E-1, 0.1 + 0.2 ->
  30000000000000004E-17, 1e-20 -> 1E-20; -0.0 -> negative zero.

A converted double may have up to 17 significant digits; sending it to a
DECFLOAT(16) throws OverflowException instead of being silently rounded
(this relies on the encoder range check of the previous commit).

Random.NextInt64() never returns a negative value, so the random doubles
were all positive. Use the full long range and assert both signs are covered.