string.format extension should output scientific notation consistent with CEL spec

[zeitgeist87]

Describe the bug
The string.format extension currently outputs scientific notation rendered using a unicode multiplication sign × and superscript for the exponent 2.718280 × 10⁰⁰.

To Reproduce
Check which components this affects:

• parser
• checker
• interpreter
• string.format extension

Sample expression and input that reproduces the issue:

"%e".format([2.71828])

Test setup:
Existing test case.

Expected behavior
The output should instead be conforming to the CEL spec: 2.718280E+00 or 2.718280e+00

FLOAT_LIT      ::= -? DIGIT* . DIGIT+ EXPONENT? | -? DIGIT+ EXPONENT
DIGIT          ::= [0-9]
HEXDIGIT       ::= [0-9abcdefABCDEF]
EXPONENT       ::= [eE] [+-]? DIGIT+

[TristonianJones]

It turns out there were two issues:

• One is that golang seems to introduces narrow spaces during formatting which are not part of CLDR and the ICU4C libraries: x/text/message: scientific format is incorrect golang/go#71428
• The other is that the option to enable localization of the exponent was not obvious in C++.

It appears that both issues will be addressed, but the scope of this bug will be to temporarily strip narrow spaces on exponents until Golang updates to support the same.

[liggitt]

The output should instead be conforming to the CEL spec: 2.718280E+00 or 2.718280e+00

Switching away from the multiplication sign and exponent would be a bigger change than just stripping the narrow spaces... it's not clear to me that the format library must output something that CEL could parse back as a number in the CEL grammar.

[liggitt]

golang/text@221d88c now strips the spaces in the latest tag

[TristonianJones]

@liggitt the PR from @jcking versions the format change considering it could break tests.

In looking at the complexity introduced by locales, we opted to stick with C-format and remove locales since the outputs would likely only need to be developer-readable. At some point we may introduce locales, but we won't mix developer and non-developer formatting, e.g map / list format alongside locale numeric formatting.

[liggitt]

@liggitt the PR from @jcking versions the format change considering it could break tests.

as the golang.org/x/text change did when we bumped things in kubernetes - kubernetes/kubernetes#130913 (comment)

will CEL still inherit the narrow space stripping change from x/text?

[TristonianJones]

Yes, unfortunately, it will. Do you need us to undo it in a patch?

[liggitt]

Not necessarily, just trying to figure out how we'll react downstream in a way we won't have to undo when we pull in a CEL update. I have a hard time imagining someone taking a dependency on the exact output of the current %e formatter except in a test