Like other recursive operations on the dependency graph, this is
not done in a single transaction to prevent an attacker from creating
arbitrary large transactions.
So at startup, the `ValidationManager` finds and resumes any
unfinished operations, by looking for shared messages with unshared
dependencies.
Database queries for metadata only returned it for messages that were delivered already.
However, there are cases (e.g. a pending message needs to be delivered) where
the validator needs to retrieve the metadata from the database.
For these cases, a special database query has been introduced.
This adds a new table to the database to hold message dependencies.
It introduces two more message states: pending and delivered
The valid column in the database was renamed to state to better reflect
its new extended meaning.
The DatabaseComponent was extended with three methods for:
* adding dependencies
* getting dependencies of a message
* getting messages that depend on a message (dependents)
* getting messages to be delivered (by startup hook)
* getting pending messages to be possibly delivered (by startup hook)
In order to reflect the new states, things that were previously true for
VALID messages have been changed to now be true for DELIVERED messages.
Since pending messages should not be available to clients, many database
queries have been modified to only return results for delivered
messages.
All added methods and changes should come with updated unit tests.
Please note that the database version was bumped in this commit.
* force decline when two of our own identities are introduced to each
other
* throw away introduction requests to the same identity
(impossible to trigger from UI)
Closes#284
This requires exposing the `containsContact()` method to the `DatabaseComponent`
and is needed for finding out efficiently whether a contact already exists.
Avoid potential deadlock in TransportKeyManager. #235
See rambling description on the ticket and in the architecture channel...
Fixes#235.
See merge request !79
