If a keyring is empty, store a no data flag instead of failing.

Any fully empty keyring (no keys and no applications) would fail to add
the empty flat buffer and thus prevent the whole keystore database from
being stored. This could easily happen when you used separate keyrings
but the master keyring was left unused for example.

Adding a flag that tells that there is no data allows us to distinguish
between a case where the stored data is missing due to a problem versus
an actually empty buffer.

Add missing check for unlocked state.

Introduce keyring unlock key concept.

* Rename fKeyMessage to fUnlockKey and the KeyMessage() getter to
UnlockKey().
* Keep track of whether the keyring has an unlock key set.
* Store and restore that info separately.
* En- and decryption will depend on unlock key presence later.
* Add functions to set and remove an unlock key and query for it.

Store each keyring in a message under a common keyrings field.

* Each keyring is now stored in a proper message which allows it to
contain additional meta data along side the flat data.
* Adding all keyring messages under a common field also allows to add
meta data to the keystore, as the keyrings don't use up random field
names anymore.
* Treat the master keyring as any other keyring and just add it to the
list. This allows to write/read the keystore database without special
casing the master keyring.

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.

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.

Allow for all entries of an application to be removed.

Add application iteration method.

Add application info handling into the Keyring class.

Only write and encrypt the flat buffer when modified.

Restructure how keyrings are stored/restored.

* Pass them through a flat buffer that can later be encrypted and
decrypted in a central place.
* Remove the data argument from the constructor as keyrings are
now reading their data on their own.
* Prepare for additional application info storage in the keyring.

Store the key message from access/creation.

* Allow creating a Keyring with a key message.
* Store the key message when accessing.
* Add a few missing consts.

Implement basic keyring access logic and key request dialog.

* The keyring needs to be made accessible before allowing any
operation.
* Before executing commands the keyring is made accessible if
possible (the command is aborted as needed).
* Accessing a keyring opens up a preliminary key request dialog.
* If the default keyring is accessible and a keyring key for the
requested keyring is found, that key will be used to automatically
make the requested keyring accessible.

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.

If a keyring is empty, store a no data flag instead of failing.

Any fully empty keyring (no keys and no applications) would fail to add
the empty flat buffer and thus prevent the whole keystore database from
being stored. This could easily happen when you used separate keyrings
but the master keyring was left unused for example.

Adding a flag that tells that there is no data allows us to distinguish
between a case where the stored data is missing due to a problem versus
an actually empty buffer.

Add missing check for unlocked state.

Introduce keyring unlock key concept.

* Rename fKeyMessage to fUnlockKey and the KeyMessage() getter to
UnlockKey().
* Keep track of whether the keyring has an unlock key set.
* Store and restore that info separately.
* En- and decryption will depend on unlock key presence later.
* Add functions to set and remove an unlock key and query for it.

Store each keyring in a message under a common keyrings field.

* Each keyring is now stored in a proper message which allows it to
contain additional meta data along side the flat data.
* Adding all keyring messages under a common field also allows to add
meta data to the keystore, as the keyrings don't use up random field
names anymore.
* Treat the master keyring as any other keyring and just add it to the
list. This allows to write/read the keystore database without special
casing the master keyring.

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.

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.

Allow for all entries of an application to be removed.

Add application iteration method.

Add application info handling into the Keyring class.

Only write and encrypt the flat buffer when modified.

Restructure how keyrings are stored/restored.

* Pass them through a flat buffer that can later be encrypted and
decrypted in a central place.
* Remove the data argument from the constructor as keyrings are
now reading their data on their own.
* Prepare for additional application info storage in the keyring.

Store the key message from access/creation.

* Allow creating a Keyring with a key message.
* Store the key message when accessing.
* Add a few missing consts.

Implement basic keyring access logic and key request dialog.

* The keyring needs to be made accessible before allowing any
operation.
* Before executing commands the keyring is made accessible if
possible (the command is aborted as needed).
* Accessing a keyring opens up a preliminary key request dialog.
* If the default keyring is accessible and a keyring key for the
requested keyring is found, that key will be used to automatically
make the requested keyring accessible.

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.