Plugin API: asynchronously replays persistent messages. Implementations replay a message by calling replayCallback. The returned future must be completed with the highest sequence number when all messages (matching the sequence number bounds) have been replayed. Journal must maintain the highest sequence number and never decrease it. The future must be completed with a failure if any of the persistent messages could not be replayed.

The toSequenceNr will either be Long.MaxValue to replay all messages or otherwise a limited upper sequence number. When replaying all messages the returned highest sequence number should be the same as the last replayed message, and the implementation would typically not have to read highest sequence number in other way than replaying the messages. With a custom toSequenceNr the implementation would typically have to both replay messages and read the actual highest sequence number.

One special case is toSequenceNr of 0, which means that no messages should be replayed, but the returned highest sequence number must still be the highest of all stored messages. In this case the implementation would typically have to read the actual highest sequence number but can skip replay of messages.

This call is NOT protected with a circuit-breaker because it may take long time to replay all events. The plugin implementation itself must protect against an unresponsive backend store and make sure that the returned Future is completed with success or failure within reasonable time. It is not allowed to ignore completing the future.

Please also note that requests to replayMessages may be made concurrently to writes executing for the same persistenceId, in particular it is possible that a restarting actor tries to recover before its outstanding writes have completed.