v2.9.4

1. Fixed data inconsistency due to outdated transactions, see details below:
   Since we use connection pools, connections are not newly created and re-used. Thus, there may be a transaction opened previously when a connection is acquired. Due to database transaction isolation level set to READ REPEATABLE, updates made after the transaction was opened are not reflected in the transaction. As a solution, we would run ROLLBACK and BEGIN on all newly acquired connections, to ensure that the previous transaction is closed and a new transaction is started.
   Credit: Thanks to @dowmeister for helping with this issue.
2. Improved sub-application startup and shutdown event (aka, lifespan) handling, see details below:
   Due to FastAPI/Starlette not supporting lifespan events in sub-applications, we previously called startup event with middleware when the first request is sent in, which potentially leads to database connection timeout due to lack of available connections in connection pool. To solve this issue, we are now calling startup event for sub-applications one by one from main application lifespan event. In addition, the function to close database connection pool on shutdown is added, so the database could be shutdown more gracefully.
3. Added retries and supported optional increased timeout for database connection acquisition, see details below: To further reduce the possibility of Timeout errors, we added retries on connection acquisition. Also, considering that we attempt to acquire a number of connections on startup and this may lead to lack of available connections, the timeout on connection acquisition for functions executed in startup event is increased to 10 seconds.