Harden Elasticsearch tests against container startup flakes

[danielgerlag]

Describe the change

Elasticsearch-Tests has been failing on master and open PRs (including #1443 / #1444) while every other provider job stays green. The failure is not an assertion flake in the indexer: all 7 tests die in ElasticsearchDockerSetup.InitializeAsync with:

Initialize sequence timed-out
GET /_cluster/health?wait_for_status=green
Connection refused (127.0.0.1:<mapped-port>)

Squadron starts docker.elastic.co/elasticsearch/elasticsearch:7.17.29 and then polls cluster health green through NEST. The mapped port never accepts connections within the 5-minute timeout (single-node bootstrap / mmap / geoip download / NEST product-check during startup). Last time this job was green on this repo was around October 2025; recent master runs fail the same way every time.

Describe your implementation or design

Test-only hardening. No production Elasticsearch indexer behavior change.

1. Replace Squadron with Testcontainers ContainerBuilder (same approach as Azure/Oracle tests).
2. Pin ES 7.17.29 (matches NEST 7.x used by the provider).
3. Single-node env that actually starts on GHA ubuntu-24.04: security/ML/geoip off, node.store.allow_mmap=false, 512MB heap.
4. Wait for HTTP 200 on /_cluster/health (yellow is fine) instead of NEST wait_for_status=green.
5. Unique index name per test instance; refresh the index instead of Thread.Sleep(1000).
6. Raise vm.max_map_count in the Elasticsearch CI job.

Tests

Existing SearchIndexTests (7 facts) still cover search/filter. They now prove documents are searchable after an explicit refresh on an isolated index.

This environment has no Docker daemon, so the tests were compiled (net8.0) but not executed here. CI Elasticsearch-Tests is the real verification.

Breaking change

No.

Additional context

Failing test names (all same fixture timeout):

• should_search_on_reference
• should_search_on_custom_data
• should_filter_on_custom_data
• should_filter_on_alt_custom_data_with_conflicting_names
• should_filter_on_reference
• should_filter_on_status
• should_filter_on_date_range

The refresh-race / shared-index hypothesis was not the current CI failure. Unique indexes + refresh are still included so those races cannot return once the container starts.