Endpoint for Togglz Feature Flags

Summary

Add an authenticated CDA endpoint that exposes the Togglz feature flags currently active on the running server.

Suggestions:

• GET /admin/features
• GET /features

The endpoint should allow authenticated users, and possibly only admin users, to view which server-side feature flags are set at runtime.

Problem

PR #1785 improves how CDA loads default feature properties from the classpath when no external Togglz properties file is configured.

That helps make the configured defaults work correctly, but it is still difficult to confirm what feature state is actually active on a deployed server. A runtime endpoint would make it easier to verify whether packaged defaults, mounted features.properties, or -Dproperties.file=... overrides are the values CDA is actually using.

This would be especially useful when debugging environment-specific behavior. Currently there's stack-trace inclusion, object-storage blob behavior, and auth compatibility flags.

Proposed Behavior

Add a read-only endpoint that returns the current Togglz feature states known to CDA.

Suggested response fields:

• feature name
• enabled/active state
• label/description, if available from the Togglz annotation

Something like:

{
  "features": [
    {
      "name": "INCLUDE_ERROR_STACK_TRACES",
      "enabled": true,
      "label": "Include stack traces in JSON error responses for authorized debug requests"
    }
  ]
}

Start by tracing the existing authenticated CDA endpoint patterns and the Togglz configuration described alongside PR #1785, including packaged defaults, features.properties, and -Dproperties.file overrides. Define the read-only GET /admin/features or /features response around the runtime feature states and available labels, and verify that the endpoint exposes the intended authenticated or admin-only view.