Add IndexMode.TSDB as the preferred metrics mode

[kkrik-es]

Summary

Add IndexMode.TSDB as a new, first-class enum value that behaves identically to TIME_SERIES (delegates every overridden method), so index.mode: tsdb is now accepted anywhere index.mode: time_series is — without renaming or changing anything about existing time_series indices, which keep emitting/persisting exactly as before (time_series remains the canonical output string; tsdb is a preferred alias).

• New helpers IndexMode#isTsdb(), IndexMode.isTsdb(IndexMode) (null-safe), and IndexMode.isTsdbName(String) (for raw, un-parsed index.mode setting strings) replace direct == IndexMode.TIME_SERIES comparisons across the codebase, so both spellings are treated identically everywhere.
• Enum.valueOf(IndexMode.class, ...) / IndexMode.valueOf parse sites were deliberately left untouched — since TSDB is a new constant (not a rename) whose name already uppercases to match "tsdb", these already accept both spellings for free.
• New TransportVersion (index_mode_tsdb_added) gates TSDB's wire serialization for mixed-version clusters.
• New TsdbIndexModeTests covering fromString, getName, isTsdb/isTsdbName, the index.mode setting parser, serialization round-trip + version-gate failure, and behavior parity with TIME_SERIES.
• New TimeSeriesToTsdbIndexModeRollingUpgradeIT — a real rolling-upgrade test that creates a data stream on time_series, upgrades the cluster, switches the template to tsdb and rolls over, and verifies the old backing index stays time_series, the new one is tsdb, and both remain queryable together (verified via FROM ds METADATA _index | STATS count = COUNT(*) BY _index).

Notable bugs found and fixed along the way

• EsqlSession's _index_mode term filter (used to gate TS/PROMQL command queries) was built from the command's fixed sentinel mode, so it only ever matched "time_series" — it would have silently excluded any concrete index.mode: tsdb index from a TS query, and incorrectly rejected it as "not a time series index" on retry. Fixed with a TermsQueryBuilder matching both aliases.
• Two colon-style switch/if statements (FollowingEngineTests, LogsdbIndexModeSettingsProvider) with a default/hardcoded branch would have broken once TSDB became reachable via randomFrom(IndexMode.availableModes()) — not caught by the compiler since these aren't exhaustive expression switches.
• A couple of randomValueOtherThan(IndexMode.TIME_SERIES, ...) test patterns would let a randomly-picked TSDB slip through as "not time series," causing spurious failures — fixed with randomValueOtherThanMany(m -> m.isTsdb(), ...).

Test plan

• TsdbIndexModeTests (new) — all pass
• IndexSettingsTests, MapperServiceTests, MappingLookupTests, IndexModeFieldTypeTests, SourceFieldMapperTests, PerFieldMapperCodecTests, TSDBDocValuesFormatSelectorTests, ResolveIndexTests — all pass
• ESQL analysis, optimizer, datasources, session test suites — all pass
• FollowingEngineTests (ccr), IndexCommitTimestampFieldRangeTests (stateless) — all pass
• TimeSeriesToTsdbIndexModeRollingUpgradeIT (new) — run against real rolling upgrades from both 9.5.0 and 8.19.0
• Full compile sweep across every touched module
• spotlessJavaCheck clean across every touched module

Follow-up (separate PR)

Updating YAML REST tests and existing Java tests to prefer/cover tsdb alongside time_series is intentionally deferred to a follow-up PR.

Related to #152902

[elasticsearchmachine]

Hi @kkrik-es, I've created a changelog YAML for you. Note that since this PR is labelled release highlight, you need to update the changelog YAML to fill out the extended information sections.

[elasticsearchmachine]

Pinging @elastic/es-storage-engine (Team:StorageEngine)

[github-actions]

🔍 Preview links for changed docs

⏳ Building and deploying preview... View progress

This comment will be updated with preview links when the build is complete.

[github-actions]

ℹ️ Important: Docs version tagging

👋 Thanks for updating the docs! Just a friendly reminder that our docs are now cumulative. This means all 9.x versions are documented on the same page and published off of the main branch, instead of creating separate pages for each minor version.

We use applies_to tags to mark version-specific features and changes.

Expand for a quick overview

When to use applies_to tags:

✅ At the page level to indicate which products/deployments the content applies to (mandatory)
✅ When features change state (e.g. preview, ga) in a specific version
✅ When availability differs across deployments and environments

What NOT to do:

❌ Don't remove or replace information that applies to an older version
❌ Don't add new information that applies to a specific version without an applies_to tag
❌ Don't forget that applies_to tags can be used at the page, section, and inline level

🤔 Need help?

• Check out the cumulative docs guidelines
• Reach out in the #docs Slack channel

[felixbarny]

Instead of creating a whole new IndexMode, have you considered keeping just the existing TIME_SERIES one but accepting two string representations for it? If feasible, that seems like a smaller, more contained change.

[kkrik-es]

I did, this mostly works but there are cases where we invoke Enum.valueOf(IndexMode.class, ..). This doesn't like different strings and may fail in weird ways. There's also a question how we serialize in this case - use time_series or tsdb in the output?

It's cleaner to introduce a new mode and start using it - although it's quite a change to make sure it's used and tested everywhere..

[kkrik-es]

Adding @dnhatn for the esql part, @gmarouli for lifecycle and downsampling.

[gmarouli]

Instead of creating a whole new IndexMode, have you considered keeping just the existing TIME_SERIES one but accepting two string representations for it? If feasible, that seems like a smaller, more contained change.

Renaming could be considered a breaking API change. Currently, there might be users relying on this string to detect their time series data. So, we have 2 options but they have trade-offs:

1. Add a new one, prefer it when a user doesn't explicitly specify time_series.
   We can use tsdb as a default, for example, when we perform the migration, if tsdb is supported by all nodes. We could change our managed templates (again as long as the cluster is fully upgraded), but we shouldn't overwrite the user's input. This is the conservative approach.

2. We simply rename it in the API. The wire serialisation of the enum is based on the byte id, so that's not an issue, but we need extra care on the XContent serialisation and we need again a cluster feature to ensure that the cluster state recovery will not encounter any issues when parsing XContent. And we need to inform our customers about this because it will change on every output, component and composable templates, settings, data streams etc.