Fix Decimal float values

[ansscfc]

Hurl version = 1.4.0

I've come across an issue where hurl appears to not be interpreting decimal float values as it should.

For example, with a hurl file such as this simplified version below where foo is a float, the assert fails:

POST {{base-url}}/{{endpoint}}
...

[FormParams]
foo: 1.07

HTTP/* 200

[Asserts]
jsonpath "$.foo" == 1.07

The error returned by hurl is:

"actual:   float <1.70000000000000064>\nexpected: float <1.70000000000000000>"

Notice that the 0 before the 7 is missing, the issue is not just the 0000000000000064.
This inaccuracy is reproducible with any decimal float value I've tested with. Even if the test passes it seems to be because the assert and foo value have both been the same incorrect float.

I can see that the response body contains the correct value:

Response body: "{\"result\":\"success\",...\"foo\":1.07,...}

I can see in the UI of my app that the correct value (1.07) has indeed come through and is displayed, so from what I can tell the issue appears to be with hurl.

[fabricereix]

Thanks for reporting this bug.
This is indeed reprodicible for different float values.
We will fix it for the next release.

[fabricereix]

The fix (#365) has been merged into master. Thanks @ansscfc again for your detailled reporting.
Until the next release, the current Hurl snapshot can be downloaded from the artifact https://github.com/Orange-OpenSource/hurl/actions/runs/1487716946#artifacts.

The Float type in Hurl is now using directly the floating type f64.

The same float value can be defined from different textual values in both Hurl files and JSON HTTP responses.

Trailing zero can be added "naturally" to the value
For example, 0.07 and 0.070 have the same float value.

On the contrary, it is less intuitive, but values can be defined with a precision that the float can not encode.
For example,
0.3333333333333333333 (19 decimal digits) have 3 decimal digits too many, and be simply decoded as 0.3333333333333333 (16 decimal digits).

We could throw a parsing error when this occurs in a Hurl file. For values in JSON response, this might be more tricky to detect as we currently decode them using the serde_json API.