async/await support

[lights0123]

Let me start with this: I'm happy to write all this myself, but I'd like to know if this would be accepted upstream (and thus I should keep it as API-compatible as possible) or not.

I'd like there to be an efficient (roslibjs is pretty good for JS, but it's not efficient at all), async/await-first ROS library in any language really, but I think Rust is the best bet for that. I want to be able to handle service requests, asynchronous messages, etc. all without spawning a bunch of threads, and use all the cool stuff possible with it like select!ing between the first available message efficiently.

There's two ways I could go about doing this:

• having two separate versions of everything: a blocking and non-blocking version
• internals always use async, and expose existing APIs as simple block_on wrappers

I would certainly lean towards the second option, as there would only be one backend to maintain. Some executors (like smol) are very small, so they wouldn't increase the binary by much (only a few KBs) and could possibly speed up even existing blocking APIs.

[adnanademovic]

It might be better to make a separate library that uses async/await. The "thread for everything" approach is what is done in the official ROS clients. Working with async/await forces things into a single thread to process IO bound actions.

The library was created before futures were a thing, so even things that would be better with green threads are using OS threads. In those areas I'd say that switching to an async/await solution would be an advantage for sure. A good example would be the XMLRPC server and client each node exposes to communicate with roscore.