[FEATURE] Add GRPC/Protobuf support to Java client

Is your feature request related to a problem?

https://github.com/opensearch-project/OpenSearch/issues/16787 introduces GRPC/Protobuf as a new protocol/schema for client-server APIs, which has shown great performance improvements compared to traditional HTTP/REST APIs. This feature is now moving towards maturity and stabilization.

To further this feature's integration within the OpenSearch ecosystem, we would like to propose adding GRPC/Protobuf as a supported protocol in OpenSearch language clients. This will allow:

• users to more easily be able to use this feature, rather than raw protobuf generated code
• have shared common utilities which all clients can benefit from
• maintain parity with the HTTP/JSON user experience.
• Offer a more seamless transition from HTTP APIs to GRPC ones (e.g. through adding a flag to toggle --protocol={grpc,http})

What solution would you like?

Add gRPC transport support to the OpenSearch Java client, providing a high-performance alternative to the existing HTTP transport while maintaining full API compatibility.

Some questions/challenges to consider are:

1. Reuse HTTP java classes vs. build new ones: Whether the existing java classes can be refactored to support GRPC as well. If not possible, another option is to build a new GRPC Java code path which gets generated differently from the HTTP ones, which
2. Handwritten vs. auto-generated client If the GRPC code path is separate from the HTTP code path, should we handwrite the java client for GRPC, or is there a way to autogenerate it similar to the HTTP one? There could be divergences from spec and protobufs (due to protobuf best practices), so how can autogeneration work? Should it be generated from the API spec or opensearch-protobufs?
3. Full support vs. partial support: Depending on the challenges for supporting a fully fledged GRPC client, shall we opt to provide support only on utilities for common patterns? Can we fallback on using the default generated protobuf language client for APIs which are not supported by the client yet?
4. Protocol specific considerations: Is there a way for the Java client support gRPC-protocol-specific features, such as streaming? On the other hand, how can the client properly convert HTTP-specific features, like the bulk NDJSON format?
5. User migration: How should users transition from HTTP to gRPC (e.g. --protocol={grpc,http} flag for a seamless transition, or would they have to rewrite their code to adhere to the GRPC client?

What alternatives have you considered?

Using the generated Java code for protobufs directly, rather than integrating into the existing client architecture.

Do you have any additional context?

• How protobufs are generated from spec: https://github.com/opensearch-project/opensearch-api-specification/issues/677
• opensearch-protobufs repo where protobufs are stored: https://github.com/opensearch-project/opensearch-protobufs/blob/main/protos/schemas/common.proto
• How the GRPC core module uses the protobufs: https://github.com/opensearch-project/OpenSearch/blob/main/modules/transport-grpc/build.gradle#L37

Start with the existing HTTP transport in the OpenSearch Java client, then read common.proto in opensearch-protobufs and the transport-grpc build.gradle entry in OpenSearch. Clarify whether the client should reuse existing classes, generate a separate gRPC path, or provide partial support. Done means an agreed Java gRPC transport approach with API compatibility and migration behavior defined.