Feature: Adapter trait with optional async

[Totodore]

Make a version of the adapter trait async. This will allow remote adapter implementation (e.g redis adapter, mongodb adapter).

[Shorakie]

does the maybe_async crate cut it?

[Totodore]

Yes, it is a good idea, but it implies to also apply maybe_async on Operators and Socket structs to maybe return futures from the adapter.

[ElijahJohnson5]

This would be awesome to have! Really enjoy the work you are doing on this

[headironc]

I think there may be scenes that require both async and sync.

[Totodore]

Sure, the compatibility with previous sync code and the possibility to use both are my main blocking points to move on on this feature.
Currently one of the approaches I considered is using Operators to express multi-node async code and keep sync operations on emit/room/ns by default.

socket.emit("test", ()); // default sync behavior that will emit only from this node.
socket.async().emit("test", ()).await; // async behavior shared between nodes.

Other possibilities are:

• to use feature flags to transform all sync function to async when enabling the async feature on but it would break the default sync feature and features should always be additive for these reasons.
• To remove sync possibilities on emit/rooms/ns functions and to have everything async by default.

[Totodore]

The PR #395 solves the async adapter issues. However before merging this to the main branch I want to be sure that we have a stable trait for all the adapter implementations.

Therefore the PR #395 will be merged on the feat-adapter-rework branch. And the adapter implementions should be worked on this branch. I would like to have at least 2 implementations (maybe redis and mongo before merging everything to main and making a release).

Currently the Adapter trait is in the socketioxide crate, but I would like to put it in the socketioxide-core crate so that custom adapter implementations only depends on the core crate. Also the implementations should live in this repository in the crates folder.

@torto once PR #395 is merged, would you still like to work on a Mongo adapter (See issue #361)?. I will personnally try to work on a Redis adapter.