Fix Deadlock risk

[willhoy]

1. actionConfirmOnThreadPool acquires the shared mutex and invokes the user-provided callback while still holding the lock. If the callback calls send(), then this thread tries to reacquire the shared mutex in registerUniqueCallback. This results in deadlock.
2. Even if this didn't deadlock, it would register as a duplicate because the GUID isn't erased from the callbackMap until after the callback executes.

Neither behavior is documented. The callback should be invoked after the mutex is released, and the GUID should be erased from the map before the callback is invoked.

void actionConfirmOnThreadPool(...)
{
    rmqp::Producer::ConfirmationCallback cb;
    {
        bslmt::LockGuard<bslmt::Mutex> guard(&(sharedState->mutex));
        // ... lookup, validity check ...
        sharedState->outstandingMessagesCap.post();
        cb = it->second;
        sharedState->callbackMap.erase(it);
        // check waitForConfirmsFuture here
    }
    // Callback invoked WITHOUT holding the mutex
    cb(message, routingKey, confirmResponse);
}

Proposed changes

Move the callbacks out of the critical section, this has two potentially undesirable side effects I see: without the mutex, the caller provided callback could be called multiple times in parallel where it wasn't before the waitforconfirms future could callback if the confirm callback publishes.