Allow `float[]` with `byte[]` comparisons for `cosine` and `dotProduct` for dense_vector scripting

[benwtrent]

Description

Right now, for vectors stored as element_type: byte we disallow scripting functions to be calculated with floating point query. However, if the user used some external quantization methodology, allowing the asymmetric distance calculation like this might be useful.

Since we already calculate magnitude for everything, the implementation will be fairly trivial.

The one aspect around this that might be "slow" is the actual vector ops. We have no SIMD optimized operations between float[], byte[] for dot-product. But, that should be fairly simple to do.

[elasticsearchmachine]

Pinging @elastic/es-search-relevance (Team:Search Relevance)

[thecoop]

Is there a use case for the other way? Using float doc vector with byte query vectors?

[benwtrent]

Is there a use case for the other way? Using float doc vector with byte query vectors?

I don't really see that as an important action. While it might be weird to not support it, from the end user side of things, we already support this. We just keep the byte query vector as a float. One exception might be the support for hexidecimal strings. Which, eh, I am not sure that is important for now.