mempool: release lock during app connection flush (#8986)

A manual backport of #8984.

This case is symmetric to what we did for CheckTx calls, where we release the
mempool mutex to ensure callbacks can fire during call setup.  We also need
this behaviour for application flush, for the same reason: The caller holds the
lock by contract from the Mempool interface.

Co-authored-by: M. J. Fromberger <fromberger@interchain.io>

mempool/v1/mempool.go

@@ -131,7 +131,18 @@ func (txmp *TxMempool) SizeBytes() int64 { return atomic.LoadInt64(&txmp.txsByte
 //
 // The caller must hold an exclusive mempool lock (by calling txmp.Lock) before
 // calling FlushAppConn.
-func (txmp *TxMempool) FlushAppConn() error { return txmp.proxyAppConn.FlushSync() }
+func (txmp *TxMempool) FlushAppConn() error {
+	// N.B.: We have to issue the call outside the lock so that its callback can
+	// fire.  It's safe to do this, the flush will block until complete.
+	//
+	// We could just not require the caller to hold the lock at all, but the
+	// semantics of the Mempool interface require the caller to hold it, and we
+	// can't change that without disrupting existing use.
+	txmp.mtx.Unlock()
+	defer txmp.mtx.Lock()
+
+	return txmp.proxyAppConn.FlushSync()
+}
 
 // EnableTxsAvailable enables the mempool to trigger events when transactions
 // are available on a block by block basis.