createKek previously always minted a random kek_ref id. Thread an
`identifier` through create_kek (Rust keystore + FFI + nsILockstore IDL +
service) so a caller can request a deterministic, well-known kek_ref: an
empty identifier keeps the random-id behaviour, while a non-empty base64url
([A-Za-z0-9_-]) identifier is used verbatim and makes the call an idempotent
get-or-create -- a second create with the same kekType + identifier returns
the existing KEK untouched.
This lets a consumer such as the SQLite encryption keystore (bug 1996558)
mint one shared LocalKey at lockstore::kek::local:sqlite and recover it on
every later run, rather than persisting a random ref itself.
Differential Revision: https://phabricator.services.mozilla.com/D303673
Benjamin Beurdouche
e2d590286b