The situation with elasticlient

[SwooshyCueb]

Presently, this plugin makes use of elasticlient, a C++ library for using elasticsearch. Given that this is the only repo I've found that uses elasticlient, I've opened the issue here instead of in the externals repository.

The upstream elasticlient repo's last commit was in August of 2021. There is no official C++ library for elasticsearch or open search.
elasticlient is built atop CPR, a C++ wrapper for curl. Both CPR and curl see active development. curl is in distribution repositories.

Looking at the distros we support (or plan to support), we have a wide spread of curl versions we must support:

Distro	curl version
CentOS 7	7.29.0
EL 8	7.61.1
EL 9	7.76.1
Ubuntu 18.04	7.58.0
Ubuntu 20.04	7.68.0
Ubuntu 22.04	7.81.0
Debian 11	7.74.0
Debian 12	7.88.1

CPR does not specify anywhere what versions of curl are supported by which versions of CPR, so I've done some testing of my own and found that the only version of CPR that supports building against this range of curl versions is 1.4.0. This is problematic because this version is too old for the latest version of elasticlient to build against. Additionally, Curl 8 will be landing in distros soon, and I doubt CPR 1.4.0 will be compatible.
Elasticlient does not specify which versions of CPR it can build against, and I have not tested to find the minimum version.

This hasn't come up before as our elasticlient externals package bundles both cpr and curl. Even though we have a cpr externals package, which it turns out we weren't even using.

This situation is ugly ugly ugly.

Continuing to bundle compatible versions of libcpr and libcurl with elasticlient is a bad idea for a couple of reasons:

1. We use curl elsewhere in irods. System curl. Using both system curl and bundled curl can cause problems with the different versions conflicting, both at run-time and build-time. The fact that we've avoided this so far is pure coincidence, and I have started to run into it in my testing for libstdc++.
2. We are moving towards more Normal and Boring packaging. Bundled dependencies like this is antithetical to Normal and Boring.
   • We could conceivably package a compatible curl, but in order to avoid problem 1, we would have to build everything and everything we use against our packaged curl, and given how many system-provided dependencies that also pull in curl, there would be a lot more things we'd have to package.

This means if we want to continue using elasticlient/CPR, and if we want to use system curl (and we do), we will have to drop support for some of the older distros we support for the irods server.

Additionally, CPR has already moved out from under elasticlient. As CPR and curl continue to be developed, they will eventually move out from under elasticlient, meaning there will be new distros that we will be unable to support while we are still using elasticlient.

I see two paths forward:

1. Stop using elasticlient/CPR
2. Patch elasticlient to support building against older and newer CPR, and package different versions of elasticlient/CPR depending on the available version of curl.

Based on our discussion on 2023-08-14, it looks like 1 is the most viable solution, replacing elasticlient/CPR with raw curl calls or boost beast.

[korydraughn]

Given the situation with elasticlient/CPR, we are going to hold on releasing a new version of the indexing plugin for 4.3.1.

Once we have a solution to this issue, we'll put out a new release.