ext_authz: fixed a bug to honor filter_enabled_metadata when the filter is marked with disabled=true

[agrawroh]

Description

This PR fixes a bug to honor filter_enabled_metadata when the filter is marked with disabled: true. The filter is now instantiated when filter_enabled_metadata is configured, allowing it to check dynamic metadata at runtime and enable itself conditionally.

Fix #41501

---

Commit Message: ext_authz: fixed a bug to honor filter_enabled_metadata when the filter is marked with disabled=true
Additional Description: Fixes a bug to honor filter_enabled_metadata when the filter is marked with disabled: true.
Risk Level: Low
Testing: Added Tests
Docs Changes: N/A
Release Notes: Added

[adisuissa]

cc @envoyproxy/envoy-maintainers
I would like to bring this approach into discussion, as it may cause inconsistencies later.
IMO the internal-filter logic of whether it is enabled or not (filter_enabled_metadata) should not take precedence over the HttpFilter disabled field.
I think that keeping the hierarchy clear would make both the design and implementation much simpler.
cc @wbpcode who spent many cycles on the filter's disabled field and getting its semantics correct.

Edit:
Forgot to mention, IIUC the ExtensionWithMatcher configuration can be useful here by matching some value to decide whether to invoke the filter or not.

[agrawroh]

cc @envoyproxy/envoy-maintainers

I would like to bring this approach into discussion, as it may cause inconsistencies later.

IMO the internal-filter logic of whether it is enabled or not (filter_enabled_metadata) should not take precedence over the HttpFilter disabled field.

I think that keeping the hierarchy clear would make both the design and implementation much simpler.

cc @wbpcode who spent many cycles on the filter's disabled field and getting its semantics correct.

Edit:

Forgot to mention, IIUC the ExtensionWithMatcher configuration can be useful here by matching some value to decide whether to invoke the filter or not.

@adisuissa Should I revert this change first? We can discuss more offline.

[adisuissa]

@adisuissa Should I revert this change first? We can discuss more offline.

I believe that's up to a senior-maintainer to decide on this.

[ggreenway]

@adisuissa @agrawroh I'm fine with however you want to proceed on this, whether it's revert or fix-forward. Whatever is easiest. Although if we're sure we don't want to keep the current behavior, and a replacement isn't ready before the next release (mid january I think), then revert would be better.