Example lock apps do not implement segmenting of credential database by credential type

[bzbarsky-apple]

Problem

In the door lock spec, credential indices are scoped to a particular credential type. So (RFID, index 1) and (PIN, index 1) are two different credential slots.

In the Linux lock app there is a single mLockCredentials array (verified by testing and code inspection). In the EFR32 and P6 and CYW30739 lock apps code inspection suggests the same thing is happening.

Concretely, if I run the following against the linux lock-app:

1. chip-tool doorlock set-credential 0 '{ "credentialType": 1, "credentialIndex": 1 }' "123456" null null null 17 1 --timedInteractionTimeoutMs 1000
2. chip-tool doorlock get-credential-status '{ "credentialType": 2, "credentialIndex": 1 }' 17 1
3. chip-tool doorlock set-credential 0 '{ "credentialType": 2, "credentialIndex": 1 }' "1234567890" null null null 17 1 --timedInteractionTimeoutMs 1000

Then:

• In step 2 I get a FAILURE response instead of the expected success response saying there is no such credential.
• In step 3 I get an OCCUPIED status response instead of the credential being added, as it should be.

Proposed Solution

The credential indices need to be scoped to the credential type. A flat store can still be used, if the scoping is implemented in some way on top of it, or per-type stores.

[woody-apple]

Spec Issue Review: Given there are no test cases for this, we should mark multiple credential types as provisional for v1.0 test plans.

[Dan-Matosian]

I think the simplest path forward for 1.0 is to just mark certain credential types as provisional. This would limit locks in v1.0 to only pin codes.

PR: https://github.com/CHIP-Specifications/connectedhomeip-spec/pull/5537

[woody-apple]

SDK Review: Given that this is no longer required for v1.0. Moving this out.