Reverse shutdown order of LifecycleHandlers

[AZm87]

Reverse the shutdown order of LifecycleHandlers so that handlers that depend on previous handlers are shutdown in the correct order. (#2583)

[Joannis]

This PR seems really sane to me. I'm worried if there's an impact on existing applications though. I bet @gwynne has a good idea about that, possibly a good solution. We could add a boolean to solve the migration path, with the default value being how it worked before.

[gwynne]

I don't think there's too much danger for existing applications; it's effectively useless to depend on the original shutdown order, so making it more explicitly deterministic in a useful way shouldn't be breaking unless someone was already doing something they shouldn't.

[0xTim]

This looks good and makes sense to me. I'll merge this once the release bot is back up and running

[0xTim]

Original comment:

I want my vapor backend to count the requests to allow each user only a certain number of requests.
Since there are a lot of requests, I don't want to query the database for each request just to check and decrease a counter.
Therefore I want to download the data from the database once at the beginning and then cache them locally.
This cache is then regularly synchronized with the database.
To write the data on shutdown into the database I implemented a LifecycleHandler.
The problem is, that the LifecycleHandler has to be registered after the database, because it needs the data from the database.
Because of this the LifecycleHandler's shutdown function is called when the database connection is already closed.
This leads to the fact that a new connection is created to synchronize the cache.
This connection will not be closed afterwards, because the LifecycleHandler of the database already finished.
This leads to the error "ConnectionPool.shutdown() was not called before deinit."
To solve this I reversed the order of the LifecycleHandlers for the shutdown.

[VaporBot]

These changes are now available in 4.41.8