ESQL: Fix precision of scaled_float field values retrieved from stored source

[kanoshiou]

This PR resolves the issue where different results were returned for fields using scaled_float depending on whether doc_values was enabled or disabled. This discrepancy occurred due to the extra imprecision introduced by the use of double in the calculations.

Closes #122547

[elasticsearchmachine]

Pinging @elastic/es-analytical-engine (Team:Analytics)

[kanoshiou]

I'm not sure if any additional tests are necessary, because I found a test that already covers the accuracy loss of scaled floats.

Please take a look if you have some time, @lkts. Thank you very much.

elasticsearch/modules/mapper-extras/src/test/java/org/elasticsearch/index/mapper/extras/ScaledFloatFieldTypeTests.java

Lines 85 to 88 in a59c182

	public void testRangeQuery() throws IOException {
	// make sure the accuracy loss of scaled floats only occurs at index time
	// this test checks that searching scaled floats yields the same results as
	// searching doubles that are rounded to the closest half float

[elasticsearchmachine]

Pinging @elastic/es-storage-engine (Team:StorageEngine)

[lkts]

Thank you @kanoshiou! Everything looks good to me. Can you please update ScaledFloatFieldBlockLoaderTests as well (it's new)? I have also started a CI run, let's wait for results there.

[lkts]

buildkite test this please

[lkts]

You need to add a new capability for this fix and use it in this test similar to how fix_parsing_large_negative_numbers is used above. This is needed to fix backward compatibility tests.

[kanoshiou]

Thank you for your review, @lkts ! All comments have been addressed.

[lkts]

buildkite test this please

[lkts]

buildkite test this please

[lkts]

@kanoshiou there is one more test failure that i will take care of and we should be good to go.

[lkts]

buildkite test this please

[lkts]

buildkite test this please

[elasticsearchmachine]

💚 Backport successful

Status	Branch	Result
✅	8.x

[astefan]

@lkts any reason why this hasn't been backported to 9.0 branch as well?

[lkts]

@astefan No particular reason. I figured it's not necessary given that there is no upgrade path that will "revert" this fix. E.g. you either go 9.0 -> 9.1 or 8.19 -> 9.1. I am happy to backport if needed.