Add Custom Elasticsearch/OpenSearch Mappings Support

[bountx]

Related Issue(s):

• Allow injection of custom Elasticsearch/OpenSearch mappings via configuration #544

Description:

Adds configuration-based support for extending Elasticsearch/OpenSearch index mappings via environment variables, allowing users to customize field mappings without code changes.

Features:

• STAC_FASTAPI_ES_CUSTOM_MAPPINGS - JSON string to inject custom field mappings (e.g., for SAR, datacube extensions, or performance optimizations)
• STAC_FASTAPI_ES_DYNAMIC_MAPPING - Control dynamic field mapping behavior (true/false/strict)

PR Checklist:

• Code is formatted and linted (run pre-commit run --all-files)
• Tests pass (run make test)
• Documentation has been updated to reflect changes, if applicable
• Changes are added to the changelog

[bountx]

Hi, @jonhealy1 - this PR is ready for CR :)

[jonhealy1]

Very good work here. This is a great addition! Custom mappings are definitely needed.

However, I find that passing large, complex JSON blobs via environment variables (STAC_FASTAPI_ES_CUSTOM_MAPPINGS) can be quite awkward and error-prone in deployment scenarios (escaping quotes, line limits, etc.).

Could we please add support for a file-based alternative?

For example, introduce a STAC_FASTAPI_ES_MAPPINGS_FILE environment variable.

If STAC_FASTAPI_ES_MAPPINGS_FILE is set, the application reads the JSON content from that file path.

We can keep STAC_FASTAPI_ES_CUSTOM_MAPPINGS for quick overrides.

This would allow users to simply mount a mappings.json file (e.g., via a Kubernetes ConfigMap) which is a much cleaner operational pattern.

[bountx]

Thanks! In hindsight I agree that mappings need the file-based alternative. I'll also leave current variable for quick overrides.

So priority in what actually gets to set the mapping is:
quick override > file-based mapping > default mapping

[bountx]

Hey @jonhealy1, I've implemented the requested changes

[jonhealy1]

Super cool thanks @bountx