[1.x] Allow to handle any RuntimeExceptions occurring when delivering an InboxMessage

[armiol]

This changeset addresses #1472 and brings other improvements into the codebase.

Failure of signal reception, and DeliveryMonitor to respond

InboxMessages which are processed in scope of each Delivery run, are eventually unpacked, and the respective signals are dispatched to their targets. In case a signal target is an Entity, it is possible that the signal reception does not go well for various reasons. In particular, an aggregate may have "broken" @Apply-er, making it impossible to load the aggregate state. Or, some other unexpected error may occur upon loading or storing an entity.

Previously, it was impossible to trace such failures of signal reception. And the InboxMessages causing the errors were left in their inboxes in TO_DELIVER status forever, being delivered over and over again — most likely with the same reception failure repeating.

Now, the Delivery API allows to subscribe for any failures which occur during the reception of each signal. Additionally, end-users may now choose the way to handle the reception failures in terms of action in respect to the InboxMessage of interest.

Out-of-the-box, there are two actions provided:

• mark the InboxMessage as delivered — so that it does not block further delivery of messages;
• repeat the dispatching of the InboxMessage. Please note, this is a synchronous and immediate action in terms of a delivery run.

Alternatively, end-users may implement their own way of handling the reception failure.

The corresponding functionality is provided via the API of DeliveryMonitor.

Here is a code sample:

public final class MarkFailureDelivered extends DeliveryMonitor {

    /**
     * In case the reception of the {@code InboxMessage} failed,
     * mark it as {@code DELIVERED} anyway.
     */
    @Override
    public FailedReception.Action onReceptionFailure(FailedReception reception) {

    	//// Error details are available as well:
        // InboxMessage msg = reception.message();
        // Error error = reception.error();
        // notifyOf(msg, error);

        return reception.markDelivered();
    }
}

// ...

// Plugging the monitor into the Delivery:

DeliveryMonitor monitor = new MarkFailureDelivered();

Delivery delivery = Delivery.newBuilder()
        .setMonitor(monitor)
        // ...
        .build();

ServerEnvironment
        .when(MyEnvironment.class)
        .use(delivery);

By default, InboxMessages are marked as DELIVERED in case of failure of their reception. This is so, because otherwise the issue described in #1472 arises.

Internally, such a functionality became possible by making MessageDispatcher.dispatch(envelope) to return DispatchOutcome. Previously, it was void, which was not suitable for handling any of the issues synchronously — as it was required for InboxMessage to allow users choose the way to handle the reception failures.

Other changes

It was reported, that at run-time the routing of events by their interfaces may lead to ConcurrentModificationException.
This PR addresses the issue for v1 by making the Map of signal routes concurrency-friendly. See io.spine.server.route.MessageRouting for more details.

Even more minor changes are made to fix typos and remove the unused code.

The library version is set to 1.9.0-SNAPSHOT.6.

[alexander-yevsyukov]

Please see my comments and questions.

[armiol]

@alexander-yevsyukov PTAL again.

[alexander-yevsyukov]

LGTM