QL: add unsigned_long type support

[bpintea]

This PR introduces the UNSIGNED_LONG type to QL following its availability in ES (#60050).

The type is mapped to a BigInteger whose value is checked against the UL bounds.

The SQL will now support the type as literal and in the arithmetic functions; the non-arithmetic functions however are unchanged (i.e. they still require a long / int parameter where that is the case).

The type is version-gated: for the driver SQL clients (only) the server checks their version and in case this is lower than the one introducing the UL support, it fails the request, for queries, or simply hidden in catalog functions (similar to how UNSUPPORTED is currently treated in the similar case)

The JDBC tests are adjusted to read the (bwc) version of the driver they are run against and selectively disable part of the tests accordingly.

Closes #63312

[bpintea]

Version check added to the Verifier since ideally we want only the "top" project be inspected: if the query specs an unsigned_long in a subselect, that would lead to no bwc-compatibility issues with the client.

[elasticmachine]

Pinging @elastic/es-ql (Team:QL)

[astefan]

Added a first set of reviews for almost half of the changes.

[costin]

First of, thanks for looking into this. It's a far reaching feature.
Second, it is a big PR making it hard not to produce but also review. I realize it's tricky however in the future please use a feature branch where the functionality can be built in stages (introducing the data type, checking the math operations, adding the type verification, adding the tests).
It's a tiny bit of overhead as it requires planning and waiting for reviews but it's much more digestable and easier to follow.

P.S. In fact since it took a while to get to it, I stopped at the test suite to give a first set of comments.

[astefan]

1. I think you need to add a test in FieldExtractorTestCase as well.
2. I would look into adding a field type to test_emp_copy index and have some integration tests with this field type. Look at DataLoader.loadEmpDatasetWithExtraIntoEs where this index is created with some "extra" fields in it. There is a small section there where a constant_keyword and a wildcard field are added to the mapping. And further down in the method, there are values assigned to those fields. I think the easiest way of adding an unsigned_long is to put in it the salary value and then add some minimal tests to the csv-spec/sql-spec set. In DataLoader you'd do something like this:

            for (int f = 0; f < fields.size(); f++) {
                // an empty value in the csv file is treated as 'null', thus skipping it in the bulk request
                if (fields.get(f).trim().length() > 0) {
                    if (hadLastItem) {
                        bulk.append(",");
                    }
                    hadLastItem = true;
                    bulk.append('"').append(titles.get(f)).append("\":\"").append(fields.get(f)).append('"');
                    if (titles.get(f).equals("gender") && extraFields) {
                        bulk.append(",\"extra_gender\":\"Female\"");
                    } else if (titles.get(f).equals("salary") && extraFields) {
                        bulk.append(",\"ul\":\"" + fields.get(f) + "\"");
                    }
                }

2.1. some ideas here
2.2. from the unsigned_long documentation I see a red-flag when it comes to using this field type in Scripts, as they seem they are unsupported. We need to decide if we add something to the documentation or handle this field type "nicely" and output a pretty error to the user in case the query they are building will end up using scripts (kind of hard to do I think). At the moment not even a simple SELECT CAST(u_l AS INTEGER) won't work for unsigned_long.
3. Do you think the tests we have so far answer the question "is running SELECT unsigned_long FROM test using an old JDBC driver version handled correctly both server and driver side?"

[matriv]

Left also some first comments, but need to check more.

[costin]

Left another round of comments.

[elasticsearchmachine]

Hi @bpintea, I've created a changelog YAML for you.

[bpintea]

When multiplying intervals with ulongs, the result overflows instead of failing with an overflow error

That's true, although not UL specific. I've opened #83336.

[costin]

Left yet another round.

[bpintea]

@elasticmachine run elasticsearch-ci/packaging-tests-unix-sample

[costin]

Thanks for the changes - left minor polishing comments.

[costin]

LGTM from my side.

[astefan]

LGTM

[Luegg]

Lgtm 🚀

[bpintea]

@elasticmachine run elasticsearch-ci/docs

[bpintea]

@elasticmachine update branch

[jrodewig]

@elasticmachine run elasticsearch-ci/docs

[bpintea]

@elasticmachine run elasticsearch-ci/docs

[jrodewig]

@elasticmachine run elasticsearch-ci/docs