[BUG] GroupKeyManagement ignores fabricFiltered request

[bluebin14]

Reproduction steps

1. Set up a server with 2 fabrics with some groupKeyManagement settings
2. Read GroupKeyMap and GroupTable fabric scoped list with --fabric-filtered 0
3. Resulting list only has entries from current fabric. It should have placeholder entries for the other fabric as well.

Bug prevalence

always

GitHub hash of the SDK that was being used

current

Platform

android, darwin, nrf

Platform Version(s)

No response

Anything else?

No response

[bluebin14]

./chip-all-clusters-app --passcode 12312123

./chip-tool pairing onnetwork 1 12312123

./chip-tool administratorcommissioning open-basic-commissioning-window 180 1 0 --timedInteractionTimeoutMs 10000

./chip-tool pairing onnetwork 2 12312123 --commissioner-name beta

./chip-tool groupkeymanagement key-set-write '{"groupKeySetID": 42, "groupKeySecurityPolicy": 0, "epochKey0": "d0d1d2d3d4d5d6d7d8d9dadbdcdddedf", "epochStartTime0": 2220000,"epochKey1": "d1d1d2d3d4d5d6d7d8d9dadbdcdddedf", "epochStartTime1": 2220001,"epochKey2": "d2d1d2d3d4d5d6d7d8d9dadbdcdddedf", "epochStartTime2": 2220002 }' 1 0

./chip-tool groupkeymanagement write group-key-map '[{"groupId": 1, "groupKeySetID": 42}]' 1 0

./chip-tool groupkeymanagement key-set-write '{"groupKeySetID": 43, "groupKeySecurityPolicy": 0, "epochKey0": "d0d1d2d3d4d5d6d7d8d9dadbdcdddedf", "epochStartTime0": 2220000,"epochKey1": "d1d1d2d3d4d5d6d7d8d9dadbdcdddedf", "epochStartTime1": 2220001,"epochKey2": "d2d1d2d3d4d5d6d7d8d9dadbdcdddedf", "epochStartTime2": 2220002 }' 2 0  --commissioner-name beta

./chip-tool groupkeymanagement write group-key-map '[{"groupId": 2, "groupKeySetID": 43}]' 2 0 --commissioner-name beta

./chip-tool groupkeymanagement read group-key-map 1 0 --fabric-filtered 0

./chip-tool groupkeymanagement read group-key-map 2 0 --fabric-filtered 0 --commissioner-name beta

[bluebin14]

$ ./chip-tool groupkeymanagement read group-key-map 1 0 --fabric-filtered 0
...
[1666624422597] [22068:5160187] CHIP: [DMG] }
[1666624422600] [22068:5160187] CHIP: [TOO] Endpoint: 0 Cluster: 0x0000_003F Attribute 0x0000_0000 DataVersion: 1881152597
[1666624422601] [22068:5160187] CHIP: [TOO]   GroupKeyMap: 1 entries
[1666624422601] [22068:5160187] CHIP: [TOO]     [1]: {
[1666624422601] [22068:5160187] CHIP: [TOO]       GroupId: 1
[1666624422601] [22068:5160187] CHIP: [TOO]       GroupKeySetID: 42
[1666624422601] [22068:5160187] CHIP: [TOO]       FabricIndex: 1
[1666624422601] [22068:5160187] CHIP: [TOO]      }
...
$ ./chip-tool groupkeymanagement read group-key-map 2 0 --fabric-filtered 0 --commissioner-name beta
...
[1666624458115] [22094:5160689] CHIP: [TOO] Endpoint: 0 Cluster: 0x0000_003F Attribute 0x0000_0000 DataVersion: 1881152597
[1666624458116] [22094:5160689] CHIP: [TOO]   GroupKeyMap: 1 entries
[1666624458116] [22094:5160689] CHIP: [TOO]     [1]: {
[1666624458116] [22094:5160689] CHIP: [TOO]       GroupId: 2
[1666624458116] [22094:5160689] CHIP: [TOO]       GroupKeySetID: 43
[1666624458116] [22094:5160689] CHIP: [TOO]       FabricIndex: 2
[1666624458116] [22094:5160689] CHIP: [TOO]      }

[bzbarsky-apple]

GroupKeyManagementAttributeAccess::ReadGroupKeyMap does:

        auto fabric_index = aEncoder.AccessingFabricIndex();
....
            auto iter = provider->IterateGroupKeys(fabric_index);

as in, it iterates only group keys for the accessing fabric index, instead of iterating all group keys and then deciding what to do with them.

Similarly, GroupKeyManagementAttributeAccess::ReadGroupTable does:

        auto fabric_index = aEncoder.AccessingFabricIndex();
....
            auto iter = provider->IterateGroupInfo(fabric_index);

[bzbarsky-apple]

And the group data provider API does not seem to have a way to iterate all group info or group keys across all fabric indices (but providing the fabric index in the iteration results, so the filtering can happen at the right level)....

[tcarmelveilleux]

We can emulate it by iterating over all fabrics and then doing the ReadXXX, if we know it's a non-fabric-filtered read

[bzbarsky-apple]

That information is not public on AttributeValueEncoder, to keep people from trying to do weird things and shooting themselves in the foot. We could expose it, I guess, or just do the iteration unconditionally and AttributeValueEncoder will ignore things as needed.