Add CaseInsensitive JSONExtract variants

[alistairjevans]

Adding case-insensitive JSONExtract variants makes it much easier to search unstructured/loosely-structured data in a performant manner.

For example, we know that we want to get the "level" value from some JSON in a record, but some of the JSON data has "Level".

We can take advantage of the simdjson function at_key_case_insensitive (internally it does an iteration over keys with a case-insensitive strncasecmp). Compatibility function added for rapidjson.

This won't do full multi-byte-encoding-aware case-insensitive comparisons on JSON keys, but I'd add explicit UTF8 variants if those were really needed, and only if (not sure they're needed for JSON keys).

I added a CaseInsensitive variant of all JSONExtract functions that accept a sub-path.

Changelog category (leave one):

• New Feature

Changelog entry (a user-readable short description of the changes that goes into CHANGELOG.md):

Users can now do case-insensitive JSON key lookups using JSONExtractCaseInsensitive (and other variants of JSONExtract).

Documentation entry for user-facing changes

• Documentation is written (mandatory for new features)

[CLAassistant]

All committers have signed the CLA.

[clickhouse-gh]

Workflow [PR], commit [63d5ec8]

Summary: ❌

job_name	test_name	status	info	comment
Integration tests (aarch64, distributed plan, 1/4)		error
Stress test (arm_asan)		failure
	Server died	FAIL
	Hung check failed, possible deadlock found (see hung_check.log)	FAIL
	Killed by signal (in clickhouse-server.log)	FAIL
	Fatal message in clickhouse-server.log (see fatal_messages.txt)	FAIL
	Killed by signal (output files)	FAIL

[alistairjevans]

Ah, didn't know about the aspell stuff, looks like the function names need excluding. Will fix.

[alistairjevans]

@antaljanosbenjamin, I believe I've fixed all CI issues related to my changes; seems like the failing tests may be failing on other PRs and/or be flaky? I didn't want to just blindly push a commit to retry them.

Let me know if there's anything more you'd like me to do.

[antaljanosbenjamin]

Thanks, you are right. No reason to push just for that, they might be flaky. I will check your PR today.

[antaljanosbenjamin]

What do you mean by "not to array indices or the extracted values"? I don't see how key matching is relevant for those.

[alistairjevans]

Fair, doesn't really need to be said.

[antaljanosbenjamin]

Suggested change

	> These functions may be less performant than their case-sensitive counterparts, so use the regular JSONExtract functions if possible.
	:::note
	These functions may be less performant than their case-sensitive counterparts, so use the regular JSONExtract functions if possible.
	:::

[alistairjevans]

Thanks @antaljanosbenjamin; will let you know when everything is addressed.

[alistairjevans]

A few more checks to run all checks are good barring that one flake @antaljanosbenjamin, but all your requested changes have been applied.

[antaljanosbenjamin]

Thanks for the fixes, I will check them tomorrow.

[alistairjevans]

Hi @antaljanosbenjamin, how's it looking? 🙏

[antaljanosbenjamin]

Sorry for the delay, I got swamped with more priority tasks. Checking it now.

[alistairjevans]

@antaljanosbenjamin, should I push a new commit to trigger a new build? Looks like the failing may be environmental/flake?

[antaljanosbenjamin]

Stress test - #81144
Integration tests (aarch64, distributed plan, 1/4) - all tests succeeded, but the report is broken. Will merge this.

[clickgapai]

Hi @alistairjevans @antaljanosbenjamin — while reviewing this PR I found the following:

• Bug (P1): CaseInsensitive JSONExtract functions perform case-SENSITIVE matching on JSON Object type columns — CaseInsensitive JSONExtract functions perform case-SENSITIVE matching on JSON Object type columns #102018

Happy to discuss — close anything that's wrong or already addressed.