that handles message dependencies reported from clients.
The MessageValidatedEvent has been renamed into a MessageDeliveredEvent
since there were no real use cases for the former any more.
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.
Helper class to reduce client boilerplate
* Renamed BdfReader methods for consistency with BdfList/BdfDictionary
* Added readList() and readDictionary() methods to BdfReader
* Added ClientHelper to reduce boilerplate when converting messages and metadata to and from BDF
* Moved PrivateGroupFactory to the same package as ClientHelper
See merge request !114
Unit tests for ValidationManagerImpl
Unit test for the validation manager. I also changed the way the validation manager loads unvalidated messages - instead of using a single DB task to load all unvalidated messages, it loads a list of message IDs and then loads each message in a separate task. This prevents the DatabaseExecutor from being blocked by a long-running task if there are lots of messages to validate.
See merge request !113
Please note that this commit only uses the @Test annotation
where exceptions are thrown at the end of the test,
because otherwise the test would not be executed completely.
Examples for this are in DatabaseComponentImplTest where many exceptions
are thrown in close succession or in ConnectionRegistryImplTest where an
exception is thrown in the middle of the test.
