Introduce an Elastic implementation of an embedding store

[geoand]

We should introduce an implementation of Elastic as an embedding store in the same way as we have done with PostgresSQL, Neo4j and Redis.

[geoand]

cc @yrodiere @jmartisk

[yrodiere]

IIRC there is already an embedding store for Elasticsearch in lanchain4j -- but of course we still need some work in quarkus-langchain4j. Last time I checked there were severe performance problems with that embedding store (it used brute-force KNN!), and a pending PR to solve them, but that's a different topic.

In our case, the main problem will be: which client do we use to talk to Elasticsearch.

• The low-level client is, well, low-level (you need to write JSON by hand), but can target many versions of Elasticsearch with a bit of work.
• The so-called "Java" client is easier to use, but only forward-compatible: the minute you upgrade the client version from 8.4 to 8.5, it can't talk to Elasticsearch server 8.4 anymore (or at least it's not supported). This raises problems with migration paths (if we upgrade aggressively) and CVE handling (if we upgrade at the last possible moment).
• Neither client is integrated with Vertx, they both use Apache HTTP client, but I guess that's something we can live with.

[geoand]

Neither client is integrated with Vertx, they both use Apache HTTP client, but I guess that's something we can live with.

Indeed :)