Explore acquisition scheduler offloading

[mp911de]

Reactor Pool uses a single-threaded acquisition method to dispatch pool allocation requests as the consequence of its non-blocking synchronization means. This can cause congestion on a single thread and negatively impact scalability.

We should explore whether we could obtain a Scheduler from a Connection in case it is Wrapped.

[chemicL]

Thanks! Linking the original issue reactor/reactor-pool#247. I'll test this change and follow-up. It would be neat to offer a generic reactor-pool mechanism but this approach is still great if all the r2dbc drivers can take advantage of it as demonstrated in the postgresql case.

[chemicL]

I can confirm this change brings a scalability boost where all event loops are used evenly for the processing that follows an acquisition (either a new connection or re-use from the pool). And it also feels more aligned with the SPI of r2dbc (compared to an implicit contract in reactor-pool).