Use tokio to replace async_std for plugins and backends.

[evshary]

Related to #1257

[Mallets]

@wyfo do you mind reviewing this PR?

[YuanYuYuan]

BTW, if we decide to use another static Tokio runtime in the plugin and consequently remove the async-std dependency in zenoh-util, we can eliminate the outdated TimedEvent since it was used before Tokio-utils was available.

[Mallets]

BTW, if we decide to use another static Tokio runtime in the plugin and consequently remove the async-std dependency in zenoh-util, we can eliminate the outdated TimedEvent since it was used before Tokio-utils was available.

We need to double check first wether TimedEvent is used in any plugin. In any case I'd consider the TimedEvent out of scope of this PR.

[YuanYuYuan]

A quick search over our eclipse project shows we use TimedEvent in the zenoh-plugin-dds, zenoh-plugin-ros2dds, and zenoh-backend-influxdb. And I agree that we should open another PR dedicated to cleaning this last async-std dependence in zenoh.

[Mallets]

A broader discussion should happen on wether every plugin has its own executor or a common executor can be used when statically linking the plugins.

[Mallets]

Discussion happened on Discord and there is a common agreement to go for a single runtime in case of static linking.

To deal with static vs dynamic linking and symbols re-export S3 backend uses the dynamic_plugin feature to selectively activate ad-hoc support for each target. We should explore that approach and to eventually make it common to all plugins.