Simplified fetching API

[jeckersb]

The current API is a bit cumbersome with regards to decompression and correctly managing the blob/driver semantics to successfully drive the futures to completion.

Really most of the time the client just wants the tar stream. So add a new API wherein the client can supply decompression code (and we can implement some default reusable decompressors for gzip/zstd) and in return the client receives a single future that they can await.

[allisonkarlitskaya]

Bonus points if we can move the decompression to another thread without adding too much overhead... tokio has a Duplex stream that might help with this.

[allisonkarlitskaya]

I think my ideal API would be something like:

let handle: ImageHandle = whatever_start_function("image-type:image/reference/path")?;
handle.get_raw_config() -> [u8];
handle.get_raw_manifest() -> [u8];
handle.get_config() -> oci_spec::Config;
handle.get_manifest() -> oci_spec::Manifest;
handle.layers() -> Iterator<Item = LayerHandle>;
  in such a way that:
    - the layers from the manifest and the config are lined up (the spec says they must align)

layer_handle.get_layer_id() -> Sha256;  // uncompressed tar checksum, per config
layer_handle.get_blob_id() -> Sha256; // compressed stream as per manifest
layer_handle.read_tar() -> AsyncRead;
  in such a way that:
    - we are guaranteed that the bytes have been sha256 checksumed in-process and equal the layer ID
    - we get the blob from skopeo by its ID in the manifest (skopeo varifies the sha of the blob)
    - we decompress in a thread
    - (possibly in the same thread as the decompression) we take a sha256 for the layer ID
    - we return the decompressed tar stream
    - if skopeo fails the checksum on the compressed stream or our own checksum fails to match the layer ID from the config, we return an error before we return EOF

it should be supported to get the layers in the correct layer order (as per the config/manifest) but it should also be possible to sort by (descending) size so that we can start the larger downloads first...

[cgwalters]

To combine a few threads here, maybe we should have a "get_multiple_blobs(descriptors: &[&Descriptor], max_concurrency: Option) -> impl Stream<Item=LayerReader>` or so?

The impl Stream here would be like a struct GetMultipleBlobs that would also handle calling driver/FinishPipe.

[cgwalters]

OK #83 I think will greatly help here.