[SL-UP] Split unique id and persistent unique

[jmartinez-silabs]

The Latest Specification made it clear that the Unique ID used for the rotation Device ID and the UniqueID attribute from the basic information cluster are not the same.

Our previously provisioned UniqueID remains untouched but it is now renamed PersitentUniqueID to make it clear it is not the same as The UniqueId Attribute as presented in spec.

The UniqueID attribute from the basicInformation value is now stored in our NVM3 config section. It is erased on factory reset. After factory reset, at init, we will generate a random unique id. A user can store a New UniqueID at runtime if he decides to with StoreUniqueId()
This code already exists so the only change in this PR on this topic is having the kConfigKey_UniqueId in the NVM3 config section which is erased on factory reset

Also ReturnErrorCodeIf doesn't exist anymore so replaced with VerifyOrReturnError

[mykrupp]

Is there any consideration for a user that has a project where they use kConfigKey_UniqueId to retrieve a rotating id key at (kMatterFactory_KeyBase, 0x1F) ? Now kConfigKey_UniqueId would be pointing to a different location in nvm for them.

[jmartinez-silabs]

@mykrupp

Is there any consideration for a user that has a project where they use kConfigKey_UniqueId to retrieve a rotating id key at (kMatterFactory_KeyBase, 0x1F) ? Now kConfigKey_UniqueId would be pointing to a different location in nvm for them.

So the Rotating ID generation still fetches the uniqueID in nvm3 key at kMatterFactory_KeyBase, 0x1F. It is now renamed PersistentUniqueID. This is the right UniqueID that should never change during the life of the product and is written at provision time.

The apis to do that did not change
example

    err = DeviceLayer::GetDeviceInstanceInfoProvider()->GetRotatingDeviceIdUniqueId(rotatingDeviceIdUniqueIdSpan);
    SuccessOrExit(err);
    err = ConfigurationMgr().GetLifetimeCounter(additionalDataPayloadParams.rotatingDeviceIdLifetimeCounter);
    SuccessOrExit(err);
    additionalDataPayloadParams.rotatingDeviceIdUniqueId = rotatingDeviceIdUniqueIdSpan;
    additionalDataFields.Set(AdditionalDataFields::RotatingDeviceId);
#endif /* CHIP_ENABLE_ROTATING_DEVICE_ID && defined(CHIP_DEVICE_CONFIG_ROTATING_DEVICE_ID_UNIQUE_ID) */

    err = AdditionalDataPayloadGenerator().generateAdditionalDataPayload(additionalDataPayloadParams, c3AdditionalDataBufferHandle,
                                                                         additionalDataFields);

GetRotatingDeviceIdUniqueId is what read the persistenUniqueID and that was updated in the provisionLibs.

For the BasicInformation cluster, the API didn't change either. The Cluster calls the configuration manager which reads the nvm3 kConfigKey_UniqueId. Unrelated to the public API, the key is stored somewhere else in nvm3 as that one needs to be erased at factoryReset.

The only way this could impact a customer is if he reimplemented GetRotatingDeviceIdUniqueId and/or the BasicInformation Cluster but we don't have control over that.

In the release notes we will list this change/addition of PersistentUniqueID

[mykrupp]

Makes sense, the nvm3 location of the key stays the same. I was concerned about the actual key name.

User has a project that relies on kConfigKey_UniqueId to retrieve rotating id. Now they get this update and the same key name retrieves from a different location in nvm.

So yeah I think we just need a release note that highlights the rename.