It seems entirely synchronous, as it doesn't hit any await points and
additionally seems to be trigger-happy with mutex locks in inner calls,
so better be safe and prevent the future reader from thinking that this
function is async-safe.

The reason for that being not to mix the Tokio runtime and the `futures`
executor. While it's reasonable and possible to do so, I believe there's
bigger benefit for now to stick to a single executor.
It would be great if we could keep the code using 'vanilla' `futures`
crate but Tokio support is so baked in (e.g. child process harness) that
it seems that it'd require a lot more change for questionable benefit in
this case.
Doing so may yield another benefit - currently, there seems to be a lot
of disk I/O being done on a dedicated, blocking thread pool. It's possible,
now that we use a single executor, to use Tokio facilities for async I/O
if this proves to be faster when supported properly by the native
environment at some point (e.g. with `io_uring` on Linux).