Fix #123425 numerical floating point edge case

[craigtaverner]

So, this was an odd one, two seemingly identical calculations can lead to different results under extreme conditions. Floating point arithmetic edge case. These two functions do not always agree:

• double wrappedWidth = (180 - minPosX) - (-180 - maxNegX);
  • used in the test
  • results in exactly 360.0 when maxNegX was a very small negative number (about -1e-14 in the failing test)
• double wrappedWidth = 360.0 + maxNegX - minPosX;
  • used in the production code
  • Results in 359.99999999... for the same case, which is more accurate

We now use the production formula in the test. The reason I wrote the original test formula was it was more explanatory than the production code. I did not expect a different result. Running with -Dtests.iters=10000 had 6 failures (0.06%, which is a very low failure rate). With this fix there were zero failures.

Fixes #123425

[elasticsearchmachine]

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

[elasticsearchmachine]

💔 Backport failed

Status	Branch	Result
❌	8.19	Commit could not be cherrypicked due to conflicts
❌	8.18	Commit could not be cherrypicked due to conflicts
❌	9.0	Commit could not be cherrypicked due to conflicts

You can use sqren/backport to manually backport by running backport --upstream elastic/elasticsearch --pr 127982

[craigtaverner]

Backports done manually in #128014