Introduce FailedAttemptInfo for better retries

Hello.

When an event publication is failing it would be useful to know which was the cause - exception, when it happened and how many failed attempts were when retrying.

Introducing an extra parameter to EventPublicationRegistry.markFailed(Object event, PublicationTargetIdentifier targetIdentifier, Throwable exception) will help to store the exception.

The EventPublication interface would also provide List<FailedAttemptInfo> getFailedAttempts();

public interface FailedAttemptInfo {
    /**
     * Returns the time the event is published at.
     *
     * @return will never be {@literal null}.
     */
    Instant getPublicationDate();

    /**
     * Returns the exception causing the publication to fail
     *
     * @return will never be {@literal null}.
     */
    Throwable getFailureReason();
}

When users of the library will call IncompleteEventPublications.resubmitIncompletePublications we can take into account the number of failed attempts, the error and when it happened. Incomplete publications could be retriggered with a predicate like:

incompletePublications.resubmitIncompletePublications(e -> {
				if (e.getFailedAttempts().size() > 10) {
					return false;
				}
				return e.getFailedAttempts().stream()
						.map(FailedAttemptInfo::getFailureReason)
						.anyMatch(reason-> reason instanceof SomeOtherException);
			});

With this approach, the DefaultEventPublication would need to store the list of failed attempts and also for the other events-*** modules, the information needs to be persisted.

Not sure if this approach would fit the current design of the library. I could also help adding this with a PR later.

Start by reading EventPublicationRegistry.markFailed, EventPublication, DefaultEventPublication, and IncompleteEventPublications.resubmitIncompletePublications. Trace how failed publications are handled in the other events-* modules before deciding whether the proposed FailedAttemptInfo design fits. Done means failed attempts expose their dates and causes, support the retry predicate, and are persisted where required.