What this PR does / why we need it:

This PR proposes a permission model to enable the store administrator to identify which users are allowed to execute operations on each managed resource.

Granular permission enforcement identifies user roles (*) allowed to execute requested operations on
resources matched by type, optional name patterns, and tags:

Permission(
    name="reader",
    types=[FeatureView],
    name_pattern=".*risky.*",
    policy=RoleBasedPolicy(roles=["trusted"]),
    actions=[AuthzedAction.QUERY_OFFLINE],
)

Such resource partitioning allows teams working on the same set of features to share the same feature store, mitigating the risk of unexpected changes due to unauthorized operations.

The PR also adds support for managing authorization tokens from either OIDC or Kubernetes, in a configurable way.

Permission authorization enforcement is performed when requests are executed through one of the Feast (Python) servers:

• The online feature server (REST)
• The offline feature server (Arrow Flight)
• The registry server (grpc)

project: foo
registry: "registry.db"
provider: local
online_store:
  path: foo
entity_key_serialization_version: 2
auth:
  type: kubernetes

To avoid backward incompatibility with existing installations, the default authorization is not enabled (e.g., auth type
is set to no-auth) .

Feast clients can use the same configuration options to automatically retrieve the token from the authorization server
and transparently secure all the remote requests. This pattern allows the client to use the authorization infrastructure without affecting the business code.

By design, only the client requests are validated: once the endpoint execution is permitted for the original client request,
all the next service-to-service requests generated by the execution flow are automatically allowed.

Validation is typically implemented within the endpoint functions using an assertion-like style:

        assert_permissions(
            resource=FeatureView.from_proto(request.feature_view),
            actions=[AuthzedAction.WRITE_ONLINE],
        )

The PR also includes:

• Docs update to provide general description of the feature
• Unit test for all the new modules
• Integration tests to verify the server behavior while adding the authorization components
• New permission CLI command with sub-commands to explore and troubleshoot the permissions settings

Fully working examples both Kubernetes and OIDC authorization will be in another next PR.

(*) Match by role is the predefined option, but it can be customized to support any other user validation.

Other features coming soon

• Feature flag to override the store configuration and disable any permission validation
• Export validation metrics to telemetry collectors (related to feat: Instrument Feast using Prometheus and OpenTelemetry #4366)

Which issue(s) this PR fixes:

Fixes #4198