Add GET /api/v1/features endpoint

[ayushkcs]

What this PR does / why we need it

This PR implements the GET /api/v1/features endpoint for Cortex.

Background:
Prometheus introduced this endpoint (prometheus/prometheus#10022) to allow client applications (like Grafana) to programmatically discover which features and experimental capabilities a backend supports, rather than relying on brittle version-string parsing from /status/buildinfo.

Since Cortex uses a heavily modular and feature-gated architecture where version numbers do not directly map to feature availability, this endpoint is highly critical for ensuring clients can gracefully enable or disable UI features (e.g. streaming ingestion, exemplars, parquet querying) based on the actual runtime configuration of the Cortex cluster.

Technical Details & Changes Made

This PR introduces the feature endpoint and accurately maps Cortex's backend configuration flags to the standard JSON feature response format:

1. Feature Computation (pkg/cortex/modules.go):

   • Added a cortexFeatures() function that scans the root cortex.Config to build a list of currently enabled features.
   • Evaluated flags include:
     • remote_write_v2 (cfg.Distributor.RemoteWriteV2Enabled)
     • streaming_ingestion (cfg.Distributor.UseStreamPush)
     • parquet_queryable (cfg.Querier.EnableParquetQueryable)
     • tenant_federation (cfg.TenantFederation.Enabled)
     • distributed_execution (cfg.Querier.DistributedExecEnabled)
     • promql_experimental_functions (cfg.Querier.EnablePromQLExperimentalFunctions)

2. API Routing & Handlers (pkg/api/api.go & pkg/api/handlers.go):

   • Injected the computed Features list into api.Config.
   • Created featuresHandler to serialize and serve the {"status": "success", "data": [...]} JSON payload.
   • Registered the GET /api/v1/features route on both the standard Prometheus (/prometheus/api/v1/features) and legacy (/api/prom/api/v1/features) HTTP prefixes via RegisterQueryAPI.
   • Registered the endpoint on the internal querier router so that internal query frontend workers can accurately route and serve the requests.

Which issue this PR fixes

Fixes #7467

Verification & Testing

• Linter: Passed (make lint executed successfully with golangci-lint and faillint).
• Unit Tests:
  • Added TestFeaturesAPI in handlers_test.go to verify the HTTP handler's JSON marshalling and structure across various feature states.
  • Added TestCortexFeatures in modules_test.go to test the internal configuration-to-string mapping logic for all individual and combined flags.
• Test Suite: Executed and passed go test -v -tags "netgo slicelabels" for both pkg/api/... and pkg/cortex/....

Notes

• No external dependencies were added.
• The endpoint explicitly matches the JSON schema expected by Prometheus clients.
• Note that query sharding (VerticalShardSize) is configured on a per-tenant limit override basis rather than a global boolean flag, so it was omitted from the global features list to prevent false-positives for tenants where it is disabled.

[friedrichg]

Thanks for the PR

Remember Cortex is a prometheus compatible system.

We should reply something like See https://github.com/prometheus/prometheus/blob/main/cmd/prometheus/testdata/features.json

We don't need cortex features in the first PR