feat(search): add OpenSearch support via backward-compatible client abstraction

[SaitejaKommi]

Summary

This PR introduces native OpenSearch support to the project while fully preserving the existing Elasticsearch integration.

A new SearchClient abstraction layer enables the application to run against either backend engine without changing higher-level search logic. Query generation continues to leverage existing tooling, while execution is routed through a backend-compatible client layer.

Elasticsearch remains the default and fully backward-compatible engine, while OpenSearch is now available as an opt-in alternative.

---

What Changed

Added Search Client Abstraction

Created:

• search_client.py

Introduced a centralized SearchClient wrapper that dynamically routes operations based on:

SEARCH_ENGINE=

Supported operations include:

• .search()
• .index()
• .bulk()
• .indices.*

Decoupled Query Execution

Updated modules such as:

• query.py
• api.py

Replaced hardcoded direct .execute() flows with dictionary payload execution through SearchClient.

This cleanly separates:

• Query construction
• Backend execution

Normalized Backend API Differences

Implemented compatibility mappings inside SearchClient to handle differences between:

• elasticsearch-py (v8 style kwargs usage)
• opensearch-py (flat body payload expectations)

Unified Exception Handling

Exposed backend-agnostic exceptions such as:

• ApiError
• NotFoundError

This allows application code to safely catch equivalent failures regardless of selected engine.

Docker Development Support

Added:

• docker-compose.override.yml

This enables local engine swapping to:

• opensearchproject/opensearch:latest

for development and testing.

---

Compatibility

Elasticsearch

• Remains the default engine
• Existing behavior preserved
• Fully backward compatible

OpenSearch

Enabled via:

SEARCH_ENGINE=opensearch

Provides native alternative backend support without application-level changes.

---

Validation

Full verification completed successfully against both engines:

• Backend unit tests ✅
• Backend integration tests ✅
• Functional parity checks ✅
• Sorting / filtering equivalence ✅
• Document matching equivalence ✅
• Frontend build/tests ✅

Performance

Synthetic benchmarking showed comparable:

• Minimum latency
• Maximum latency
• Average latency

No regressions were observed.

---

Affected Files

• search_client.py
• query.py
• api.py
• docker-compose.override.yml

---

Notes

Any backend-specific indexing schema or bulk API differences are handled internally within SearchClient.

This PR focuses on extensibility and multi-engine support while keeping unrelated modules largely unchanged.