aruba_aoscx_show_interface: capture Filtered counters and tolerate L3/VRF/subinterface output

[julmanglano]

ISSUE TYPE

• Bugfix Pull Request
• Enhancement Pull Request

COMPONENT

aruba_aoscx, show interface

SUMMARY

Three changes to aruba_aoscx_show_interface:

1. New Filtered counters. Adds RX_FILTERED / TX_FILTERED
   capture groups + a matching ^\s*Filtered rule in the
   Statistic state. AOS-CX emits these on switches running L3
   ACLs / classifier policies; the existing template ignored them.

2. L3 / aggregate / subinterface tolerance. Adds three
   no-op match lines so previously-fatal output no longer hits
   ^. -> Error:

   • ^\s*Subinterface\s+count — emitted on parent interfaces
     that carry subinterfaces.
   • ^\s*active-gateway\s — emitted on interfaces with
     active-gateway/VRRP-style virtual IPs.
   • ^\s*VRF\s+name\s+is\s+\S+ — emitted on interfaces bound to
     a non-default VRF.

3. Two new fixtures.

   • show_interface5.{raw,yml} — exercises the Filtered
     counters, an L3-routed interface block, an admin-down
     header variant, and a No XCVR transceiver state.
   • show_interface6.{raw,yml} — two loopbacks in non-default
     VRFs (VRF_RED / VRF_BLUE), exercising the new VRF
     swallow rule.

BREAKING CHANGE

The two new Value declarations RX_FILTERED and TX_FILTERED
add rx_filtered / tx_filtered keys to every parsed record.
Existing fixtures (show_interface{,1-4}.yml) have been updated
with empty-string defaults to reflect the new schema; consumers
already defending against unknown keys are unaffected, but anyone
diffing against a fixed key set will see two new keys.

NOT INCLUDED

VRF capture (turning the VRF line into a Value rather than a
swallow) is deferred — it would require updating every existing
fixture again and the user does not currently have a captured
data sample for every interface variant. The swallow rule is
sufficient to unblock parsing on VRF-bound interfaces; promoting
to a capture group can be done in a follow-up.

[matt852]

Breaking change, so holding off on merging until ready for a new release.

[mjbear]

BREAKING CHANGE

The two new Value declarations RX_FILTERED and TX_FILTERED add rx_filtered / tx_filtered keys to every parsed record. Existing fixtures (show_interface{,1-4}.yml) have been updated with empty-string defaults to reflect the new schema; consumers already defending against unknown keys are unaffected, but anyone diffing against a fixed key set will see two new keys.

Would this be a breaking change though?

It's backwards compatible (something that used an old template would be oblivious to a new key). It's not like a key name changed or the data type (scalar or string vs list, etc).

[julmanglano]

Thanks @mjbear — agreed, "breaking" was being over-cautious. The only consumer that'd notice is one snapshot-testing against a fixed key set; anyone indexing by key name is unaffected since no existing key was renamed, retyped, or had its value format changed.

Will skip the breaking label on similar additive PRs going forward.

@matt852 — happy to drop the release hold then?

[mjbear]

Thanks @mjbear — agreed, "breaking" was being over-cautious. The only consumer that'd notice is one snapshot-testing against a fixed key set; anyone indexing by key name is unaffected since no existing key was renamed, retyped, or had its value format changed.

Will skip the breaking label on similar additive PRs going forward.

@matt852 — happy to drop the release hold then?

I feel the breaking change label isn't needed on this PR.

Letting some time pass so @matt852 has time to review.