We noticed some `BusyPool` exceptions filling up the driver queue upon IMAP query (FETCH flags for all the messages in the mailbox).
The MessageManager do batch those reads (by default by 200 for metadata)., wich then call the MessageMapper with this limit.
Some unit tests performed at the Cassandra mailbox level proved the soft filtering did badly applies, and that we were performing uneeded extra reads for the full batch read from the database.
One good mitigation strategy is to push the limit to the Cassandra query, and ensures filtering happens before the extra reads are performed.
https://projectreactor.io/docs/core/release/api/reactor/core/publisher/Flux.html#take-long- documents that it just don't propagate downstream request once a given amount is reached however it do not ensure any form of backpressure. We might want to further audit our code, looking for similar take mis-usages.