Add some Json tests #5037 -followup

[OceanOak]

No changelog

#5037 follow-up

• The float formatting precision was increased from %.12 to %.16 to match other programming languages (F#, python, and Javascript)

• The added tests that use [number]e+[pow] were removed.

[OceanOak]

Changing the float formatting precision to 16 makes it consistent with other languages. Is that sufficient, or do we want to move away from sprintf entirely?

[OceanOak]

From my reading, most languages seem to not explicitly set float formatting precision; the limitations typically are inherited from the IEEE 754 double precision standard.
Others use the the round-trip precision format "R" (link)
Some workarounds include using decimals instead of floats. Or allowing users to explicitly define precision through configuration arguments
example:

If use_decimal is true (default: True) then decimal.Decimal will be natively serialized to JSON with full precision.

some useful links and discussions:

• https://docs.python.org/3/library/json.html#:~:text=Implementation%20Limitations,decimal.Decimal.
• https://en.wikipedia.org/wiki/Double-precision_floating-point_format#:~:text=arithmetic.%5B7%5D-,JSON,expect%20no%20more%20precision%20or%20range%20than%20binary64%20offers.%5B8%5D,-See%20also
• https://stackoverflow.com/questions/74017216/deserialize-json-string-containing-arbitrary-precision-float-numbers-and-serial
• https://github.com/simplejson/simplejson/blob/aeb63ee451732b1e77008c28153380d8dd0fda20/simplejson/encoder.py#L330-L355
• https://stackoverflow.com/questions/51703481/serializing-float-with-maximum-precision-without-changing-target-type
• JObject does not deserialize double correctly JamesNK/Newtonsoft.Json#2889
• Hardcoded 15 significant digits in num_to_char.c  jeroen/jsonlite#412

I'm uncertain about our next steps. We can adhere to the IEEE 754 standard, which allows for up to 16 significant digits (link). This aligns with the consistent results we obtained while testing other languages
or maybe find a way to not explicitly use sprintf "%.16g"
Thoughts?

[OceanOak]

Paul's notes:

Here are some unorganized thoughts:

• Float.toString should be handled too? (Float.toString -> Float.parse roundtrip)?
• ChatGPT told me we might need 17 significant digits. It gave the example 0.0000000000000002220446049250313080847263336181640625 as something where it's more accurate with 17 digits than 16
• I tried that example with sprintf "%.16g" and "%.17g" and both gave me something like 2.220446049250313e-16 - is that the right answer? I don't know
• I also tried f.ToString("R") for roundtripping. Dunno what to do there.

More organized thoughts:

• sprintf is definitely not right
• we should come up with some test cases first - things that test the precision and also the UX (does the json need to be pretty as well as right? yes)
• that seems like work, so maybe settle on just doing sprintf "%.16g" or "%.17g" in this PR, and noting the rest for work later

I've tried using sprintf "%.17g" but I didn't like the result we got from some tests.
Here is an example :

Builtin.Json.serialize<PACKAGE.OpenAI.Completion.Request> (
  PACKAGE.OpenAI.Completion.Request
    { model = "davinci"
      prompt = "test"
      max_tokens = 5
      temperature = 0.7 }
) = PACKAGE.Darklang.Stdlib.Result.Result.Ok
  "{\"max_tokens\":5,\"model\":\"davinci\",\"prompt\":\"test\",\"temperature\":0.69999999999999996}"

We've decided to use sprintf "%.16g" for now and plan to remove it later.