XMPP backend delays sending replies until it receives some other communication

[nessuscity]

Describe the bug
When plugins reply to a message, the message is sent to the backend immediately. Other backends seem to process the messages correctly and the response is received quickly by the user. With the XMPP backend, messages are sent to the backend from plugins immediately, but the backend holds off transmitting the replies until it receives some other interaction, which can be any XMPP stanza.

To Reproduce

1. Set up a minimal bot example using the minimal config for text mode
2. Set up a new JID on an XMPP server so that it will not be receiving any incidental presence or iq stanzas that will hide the bug
3. Change the backend to XMPP and add the only the required BOT_IDENTITY information
4. Send !echo hello to the bot from an XMPP client that is configured NOT to send read state, chat markers, or anything else. The bot should not be receiving any stanzas except messages.
5. Receive no reply (unless the XMPP keepalive or other stanza is received at just the right time to force the reply to be transmitted, thus hiding the bug)
6. Send !echo world
7. Receive "hello" and "world" messages from the bot simultaneously.

The buffered reply is also sent automatically if the bot receives any message or other stanza from another user or the server. In the absence of any such stanzas, the bot will hold onto the reply indefinitely.

Expected behavior
The bot replies immediately with "hello"

Screenshots
Attempts from main JID to use !echo command:

Notice that when I sent a message from a separate JID to the bot, it replied on my main JID. The second time it responded on its own was due to the XMPP keepalive triggering.

Environment (please complete the following information):

• Errbot version: 6.1.9 and master branch
• OS version: Debian 11
• Python version: 3.9.2
• Using a virtual environment: yes
• Using Docker: no

Additional context
I've tested this on multiple machines with errbot from pip and from github. I believe the fact that any stanza received hides the bug is what allowed it to get thru testing. I have witnessed this behavior on another known XMPP errbot in the wild.

Logs also show that the XMPP backend's send_message method is being called at the correct time, but the actual response stanza is not sent until another one is received.

[nessuscity]

Setting BOT_ASYNC=False seems to fix the issue. I don't know enough about asyncio or threading to know if it's a bug that you can't use BOT_ASYNC=True with the slixmpp backend

[Netzvamp]

BOT_ASYNC=False doesn't fix messages to MUCs :(