Clean connections that are returned to connection pool

See @davepacheco 's comment on : https://github.com/oxidecomputer/omicron/issues/4093#issuecomment-1745470623 for some context:

Sorry, what I meant was not to try to track whether a transaction was created, but rather always issue ROLLBACK when a connection is put back into the pool. This will fail if there was no open transaction and we'd ignore the error in this context. This would be a fallback to catch cases like this, rather than relying on the consuming code to have correctly tracked this information.

What I meant about common practice is that I think other connection pools have the notion of "stuff that gets done when a connection gets put back into the pool to ensure that connections all come out of the pool in a consistent state". Here's an example from deadpool's PostgreSQL crate:
https://docs.rs/deadpool-postgres/latest/deadpool_postgres/enum.RecyclingMethod.html

They provide a few different choices with tradeoffs in terms of cost vs. completeness. RecyclingMethod::Fast does basically nothing. RecyclingMethod::Clean runs several SQL statements that close open cursors, reset any connection-local parameters that were set with set, unlock any locks that were somehow left locked, etc. (I'm surprised they don't seem to do a rollback!)

I could not find an equivalent method in bb8, to clean connections. We could upstream this support, or consider an option like https://github.com/oxidecomputer/omicron/issues/4192

Start by reviewing the referenced bb8 connection-pool behavior and deadpool-postgres's RecyclingMethod::Clean, along with issues 4093 and 4192. Determine whether the project should upstream cleanup support or add an option, and consider the work done when pooled connections are returned in a consistent state.