First version of async traits and async HTTP

[tilowiklundSensmetry]

This introduces new async traits ProjectReadAsync, ReadEnvironmentAsync, and ResolveReadAsync; mirroring ProjectRead, ReadEnvironment, and ResolveRead.

All reqwest-based implementations have been changed to async, using reqwest_middleware::ClientWithMiddleware instead of reqwest::blocking::Client.

Utility classes such as SequentialResolver should now work for both synchronous and asynchoronous use, i.e. SequentialResolver<T> is ResolveReadAsync if T: ResolveReadAsync and is ResolveRead if T: ResolveRead. To the extent possible, they try to intelligently join futures to allow concurrency.

Utility classes AsAsync[Project|Environment|Resolver]<T> and AsSync[Project|Environment|Resolver]Tokio<T> allow treating a synchronous implementation as a (trivially) asynchronous one, and to treat an asynchronous one as if it were synchronous (if provided with a tokio runtime). Traits functions to_async and to_sync_tokio have been added to all the relvant traits.

The CLI utilises the new async version of HTTP implementations, at the cost of having to pass around an Arc<tokio::runtime::Runtime>. This is a bit messy, but, I think, good enough for the moment.

NOTE: I have (for now) removed support for range requests when accessing kpar archives. In practice this was (at the moment) slower, and I couldn't find a readily available, simple, async way of implementing it.

[tilowiklundSensmetry]

@vytautas-astrauskas-sensmetry @victor-linroth-sensmetry @andrius-puksta-sensmetry I will clarify later today what would be good to review.

[tilowiklundSensmetry]

@vytautas-astrauskas-sensmetry @victor-linroth-sensmetry @andrius-puksta-sensmetry I will clarify later today what would be good to review.

My main concerns at the moment are the async versions of the traits. I did a very naive translation from synchronous constructs to futures constructs, simply replacing Iterators by Streams, made all functions async, and replaced Readers by futures::AsyncReaders. The traits are here:

• https://github.com/sensmetry/sysand/pull/74/files#diff-07bd0984150693af3ba60e1855f9dcbcf6c76864116d2d16a636d94c85859954R233
• https://github.com/sensmetry/sysand/pull/74/files#diff-048397f464c2b819b6e2993fb3294dcaa172445c5eb374640e4a3779b2f0956fR89
• https://github.com/sensmetry/sysand/pull/74/files#diff-d77f9ebd25e3946e2ecc436b5c30d2f9aa351213258b1be3fbbf910e7a56ed5bR97

There are lots of things to improve about these traits in general (for example splitting off Ext-traits and improving naming), for now I'm only concerned with the async aspects in particular.

[vytautas-astrauskas-sensmetry]

Skimmed through. I would need to start using async more extensively to see whether the design works since I do not have much experience with it. I would suggest merging and if needed changing things later.

The only thing that I did not get is why there is much commented out code. Is all of it related to range requests?

[tilowiklundSensmetry]

Skimmed through. I would need to start using async more extensively to see whether the design works since I do not have much experience with it. I would suggest merging and if needed changing things later.

The only thing that I did not get is why there is much commented out code. Is all of it related to range requests?

This is still effectively a draft merge request.

[tilowiklundSensmetry]

Ok, this appears to be mostly working now, I will try to fix the bindings and address comments.