[Feature][Integration][Java] add ElasticsearchVectorStore in Java

[twosom]

Linked issue: #321

Purpose of change

This PR implements the Java version of Vector Store functionality for Flink Agents, following the design proposal in #143. This implementation enables RAG (Retrieval-Augmented Generation) capabilities by providing vector-based context retrieval.

• Added Vector Store API with query support and document handling
• Added @VectorStore annotation for agent plan resource management
• Added context retrieval request and response events
• Implemented context retrieval action with vector store support
• Implemented Elasticsearch vector store integration
• Added ElasticsearchVectorStore RAG example with Ollama integration

Tests

API

Documentation

• doc-needed
• doc-not-needed

[github-actions]

@twosom Please add the following content to your PR description and select a checkbox:

- [ ] `doc-needed` 
- [ ] `doc-not-needed` <!-- Your PR changes do not impact docs -->

[wenjin272]

Hi, @twosom, I'll start reviewing this PR as soon as possible. Besides, this PR should be labeled 'doc-needed'.

[wenjin272]

Hi, @twosom, thanks for your contribution. Overall looks good to me. I left some minor comments about details.

Besides, due to the example requires es cluster, I will verify the example next week.

And some test cases failed, I think it is caused by the newly added built-in action, which break the agent plan verification.

[wenjin272]

Maybe could simplify to

List<Float> queryVector = Arrays.stream(embedding)
                                .boxed()
                                .collect(Collectors.toList());

[twosom]

@wenjin272
Thank you for your feedback.
But there is no float support in Arrays.stream() method.

[wenjin272]

Here we specify the TDocument to Map, could it be other types?

[twosom]

@wenjin272
Thank you for your feedback.
Good point! While Python's Document class fixes content as str, I believe this is an over-generalization. Different vector store vendors may have different document structures.

Therefore, keeping ContentT as a generic type and delegating the responsibility to each vendor implementation would provide better flexibility. This allows each integration to define its own document structure rather than forcing all vendors into a single String-based content model.