Can we make QMP commands in Rust always be coroutine safe?

[Markus Armbruster <armbru@redhat.com>]

QMP commands that perform potentially blocking I/O can profit from
running in a coroutine.  Ideally, we'd run all commands in coroutine
context: most of them don't care, a few profit.  However, some existing
commands may need fixing to run safely there.  Since we don't know which
ones do, running in couroutine context is opt-in.  From
docs/devel/qapi-code-gen.rst section "Commands":

    Member 'coroutine' tells the QMP dispatcher whether the command handler
    is safe to be run in a coroutine.  It defaults to false.  If it is true,
    the command handler is called from coroutine context and may yield while
    waiting for an external event (such as I/O completion) in order to avoid
    blocking the guest and other background operations.

    Coroutine safety can be hard to prove, similar to thread safety.  Common
    pitfalls are:

    - The BQL isn't held across ``qemu_coroutine_yield()``, so
      operations that used to assume that they execute atomically may have
      to be more careful to protect against changes in the global state.

    - Nested event loops (``AIO_WAIT_WHILE()`` etc.) are problematic in
      coroutine context and can easily lead to deadlocks.  They should be
      replaced by yielding and reentering the coroutine when the condition
      becomes false.

    Since the command handler may assume coroutine context, any callers
    other than the QMP dispatcher must also call it in coroutine context.
    In particular, HMP commands calling such a QMP command handler must be
    marked ``.coroutine = true`` in hmp-commands.hx.

    It is an error to specify both ``'coroutine': true`` and ``'allow-oob': true``
    for a command.  We don't currently have a use case for both together and
    without a use case, it's not entirely clear what the semantics should
    be.

Can we make commands written in Rust always coroutine safe?