BKeyStore: Fix code to match documentation

Make secondary identifier mandatory on GetKey convience methods that secondary identifier as parameter (and not the secondaryIdentifierOptional bool)

Fixes #18776

Change-Id: I1ae3c9c0eb80a16e18a74835d7915dfa5efbb665
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7398
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: nephele nephele <nep-git@packageloss.eu>
Haiku-Format: Haiku-format Bot <no-reply+haikuformatbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>

Launch the keystore_server on demand from BKeyStore.

This allows leaving the keystore_server closed as long as it isn't
used and still avoids having to launch it manually.

Add generic unlock key setting and removal.

* Replace {Set|Remove}MasterKey() by generic {Set|Remove}UnlockKey()
that works on a keyring.
* Implement {Set|Remove}MasterUnlockKey() on top of that.
* Rename the commands and constants accrodingly.
* Implement setting and removing keyring unlock keys.

Don't require a key when creating a new keyring.

There will be key setting/removal functions so the step of adding the
keyring and setting a key on it can be done individually.

Remove the API part of the concept of apps per key.

The application access concept is on the keyring level only for now.
Generally it probably would get pretty complicated and therefore harder
to use when application access needs to be granted on a per key basis.

Rename keyring "access/revoke" to "unlock/lock".

The unlock/lock concept just seems easier to grasp and is used in
various similar tools as well.

Add keyring specific versions of the *Application() methods.

Remove the purpose argument from all GetKey() variants.

The type is relevant and required as it determines the type of the
handed in key. The purpose however isn't actually needed and rather
inconvenient to get by depending on the situation.

Make Flatten/Unflatten public and remove IsRegistered().

The BKey doesn't know anything about the keyring concept, so the
registered info isn't really useful. May be re-added later with
keyring info as well.

Remove unneeded master access revoke command.

Revoking master access currently simply means to revoke access
to the default keyring.

Make the keystore_server keyring aware.

* Move the *Key() functions into a Keyring class.
* Retrieve and select the right keyring for various commands.
* Implement adding/removing/enumerating keyrings.
* Rework the keystore database read/write to work with keyrings.
* Sync BKeyStore::IsKeyringAccessible() with the changed message.
* Remove leftover template code from registrar.

Update the cookie from the reply message.

Move keystore message constants and use a messenger.

* The keystore backend will (at least for the time being) reside in a
separate server. This one can be reached via normal messaging, so use
a BMessenger for sending key messages.
* Move the message constants from RegistrarDefs.h into a new
KeyStoreDefs.h that also contains the server signature.
* Update the message constants to reflect the new situation.

Implement all KeyStore methods except for password generation.

* Add all relevant message constants.
* Implement the messaging to send/retrieve key info.
* Implement _Flatten/_Unflatten for sending flat BKey objects.
* Remove application list from BKey, the key can't only differ by
allowed applications as the identifiers would still collide, so the
comparison isn't needed to uniquely identify the key. The applications
can be enumerated via the BKeyStore instead.

Rename [Un]Register* functions to Add/Remove*.

Flesh out the API and implement stubs.

* Modified the API greatly to be based on BKey* instead of BPassword*.
* Added BKeyPurpose and used it instead of BKeyType. It is supposed to
indicate the purpose of a key so that an app can look up keys on a
more granular level. The BKeyType on the other hand actually
identifies the type (i.e. subclass of BKey) so an app knows how to
handle a given key or may only enumerate/use keys it is compatible
with.
* Made everything based on a raw data buffer for now, only BPasswordKey
is implemented yet which stores the (0 terminated) string into that
data buffer.
* Removed the additional data BMessage as I don't yet see where it fits
in. While I could imagine adding meta data to a key may be nice it
might be an interoperability concern when keys are shared by
different apps.
* Moved the app functions to the keystore as per the TODO, but not sure
how to actually implement them.

KeyStore and Key interface/stubs draft per Axel Dörfler.

A draft API and (mostly) stubs to back it up. Initial import of yet
unmodified sources.

Launch the keystore_server on demand from BKeyStore.

This allows leaving the keystore_server closed as long as it isn't
used and still avoids having to launch it manually.

Add generic unlock key setting and removal.

* Replace {Set|Remove}MasterKey() by generic {Set|Remove}UnlockKey()
that works on a keyring.
* Implement {Set|Remove}MasterUnlockKey() on top of that.
* Rename the commands and constants accrodingly.
* Implement setting and removing keyring unlock keys.

Don't require a key when creating a new keyring.

There will be key setting/removal functions so the step of adding the
keyring and setting a key on it can be done individually.

Remove the API part of the concept of apps per key.

The application access concept is on the keyring level only for now.
Generally it probably would get pretty complicated and therefore harder
to use when application access needs to be granted on a per key basis.

Rename keyring "access/revoke" to "unlock/lock".

The unlock/lock concept just seems easier to grasp and is used in
various similar tools as well.

Add keyring specific versions of the *Application() methods.

Remove the purpose argument from all GetKey() variants.

The type is relevant and required as it determines the type of the
handed in key. The purpose however isn't actually needed and rather
inconvenient to get by depending on the situation.

Make Flatten/Unflatten public and remove IsRegistered().

The BKey doesn't know anything about the keyring concept, so the
registered info isn't really useful. May be re-added later with
keyring info as well.

Remove unneeded master access revoke command.

Revoking master access currently simply means to revoke access
to the default keyring.

Make the keystore_server keyring aware.

* Move the *Key() functions into a Keyring class.
* Retrieve and select the right keyring for various commands.
* Implement adding/removing/enumerating keyrings.
* Rework the keystore database read/write to work with keyrings.
* Sync BKeyStore::IsKeyringAccessible() with the changed message.
* Remove leftover template code from registrar.

Update the cookie from the reply message.

Move keystore message constants and use a messenger.

* The keystore backend will (at least for the time being) reside in a
separate server. This one can be reached via normal messaging, so use
a BMessenger for sending key messages.
* Move the message constants from RegistrarDefs.h into a new
KeyStoreDefs.h that also contains the server signature.
* Update the message constants to reflect the new situation.

Implement all KeyStore methods except for password generation.

* Add all relevant message constants.
* Implement the messaging to send/retrieve key info.
* Implement _Flatten/_Unflatten for sending flat BKey objects.
* Remove application list from BKey, the key can't only differ by
allowed applications as the identifiers would still collide, so the
comparison isn't needed to uniquely identify the key. The applications
can be enumerated via the BKeyStore instead.

Rename [Un]Register* functions to Add/Remove*.

Flesh out the API and implement stubs.

* Modified the API greatly to be based on BKey* instead of BPassword*.
* Added BKeyPurpose and used it instead of BKeyType. It is supposed to
indicate the purpose of a key so that an app can look up keys on a
more granular level. The BKeyType on the other hand actually
identifies the type (i.e. subclass of BKey) so an app knows how to
handle a given key or may only enumerate/use keys it is compatible
with.
* Made everything based on a raw data buffer for now, only BPasswordKey
is implemented yet which stores the (0 terminated) string into that
data buffer.
* Removed the additional data BMessage as I don't yet see where it fits
in. While I could imagine adding meta data to a key may be nice it
might be an interoperability concern when keys are shared by
different apps.
* Moved the app functions to the keystore as per the TODO, but not sure
how to actually implement them.

KeyStore and Key interface/stubs draft per Axel Dörfler.

A draft API and (mostly) stubs to back it up. Initial import of yet
unmodified sources.