Move Deadline support to `axon-legacy`

[smcvb]

Plan of attack

As can be read through the original description below, the Axon Framework team views the integration of deadlines to essentially be a scheduled command. Hence, all that's really required to schedule a deadline, is roughly the following:

1. Pick your favorite scheduling tool
2. Wire the CommandGateway in a scheduled task to dispatch a command

And, that is it, at least for majority of cases. For more involved sagas, our new Workflow integration will be the replacement.

Meanwhile, Axon Framework 4 has a DeadlineManager interface, four concrete implementations (in-memory, Quartz, JobRunr, and db-scheduler), an @DeadlineHandler annotation, and testing integration for all of this.
On top of that, we have had numerous requests over the years to support other scheduling tools as well.

Given the ease of implementation by a user themselves, as well as a clear replacement for process management, we have decided against porting the Deadline support as-is to Axon Framework 5.

It will thus not return.

However, we comprehend this is an issue for users on Axon Framework 4 that need to migration to Axon Framework 5.
There's a plain notion of time with a deadline which blocks a simple migration from AF4 to AF5. Thus, we simply need to do something for the user.

Hence, we will instead move the required components to axon-legacy. This means the interface, implementations, and handler support will move in it's entirety to that module, purely meant for migration purposes.

From there, users can further migrate by taking one of two paths:

1. Did you use deadlines for your aggregates? Take the path suggested above, to pick your own scheduling tool, wire the CommandGateway in a task there, and have a @CommandHandler replace your deadline handler.
2. Did you use deadlines for your sagas? This support will be entirely replaced by Workflows, which already provide a means to schedule process steps to happen at a later stage.

The axon-legacy module will comply to this style once the deadline support has been ported:

1. Scheduled deadlines for aggregates become scheduled commands. The @DeadlineHandler inside a users aggregate should be replaced with a @CommandHandler. The migration path and OpenRewrite script will help with this.
2. Scheduled deadlines for sagas still trigger your saga. This requires Make Legacy Saga code usable for migration purposes #3728 to be tackled before we can work on this issue.

The above provides an avenue to migrate existing Axon code easier, while opening an avenue for the user to later migrate to the new recommend solution. Thus, custom scheduler selection together with the required message bus or workflows

The newly recommended solution Axon Framework 5 will be explained in a dedicated documentation chapter, as well as receive a migration path and OpenRewrite script change. The latter two should be part of this PR, while the documentation chapter is a separate issue.

Original Description

Description

Currently, a deadline message targeted towards an Aggregate will load the instance directly from the Repository.

Although this works, this does not take into account which Axon node is in charge of the aggregate based on consistent hashing.
This problem is easily solved by dispatching a DeadlineMessage through a CommandBus when it is triggered.

Doing so ensures the right node will take care of Deadline.

Impl. Idea

Adjusting the DeadlineMessage to be a CommandMessage implementation instead of EventMessage implementation will go a long way to achieve this.
The predicament with this, is that Saga's still deal with events rather than commands.

Hence, perhaps a merger is feasible.
Or perhaps some wrapper message type specific for command-like deadlines and event-like deadlines.

Next to this, the ScopeAware interface should be implemented by the CommandBus too.
Currently the only implementations are the Repository and the AbstractSagaManager, both directly loading the Aggregate or Saga instance upon handling the deadline.
The CommandBus implementation would instead know how to route the deadline-command to the right instance.

Note that this does require a unique type of command handler to be registered with the CommandBus.
One which is capable of finding the Aggregate repository that should load the aggregate to receive the deadline.

Additionally

Be sure to check if there are any TODOs mentioning the issue number of this issue.
If so, resolve those as part of this effort.

[smcvb]

With PR #3470, the start and shutdown handlers of all DeadlineManager implementations has been removed, in favor of registering these during registration of the component itself. Hence, when picking up this issue, be sure to set the handlers as they were before!

[MateuszNaKodach]

Something to think about while designing deadlines in AF5:
https://verraes.net/2019/05/patterns-for-decoupling-distsys-passage-of-time-event/
They implemented in in the Spring Modulith already:
https://docs.spring.io/spring-modulith/reference/moments.html