Is your feature request related to a problem? Please describe.

tame-gcs currently hardcodes the request URLs

If we want to use change the endpoints to use other GCS-compatible services e.g. fake-gcs-server, we will need to manually replace the URLs in the generated http::Request, which is awkward.

Note that the official GCS libraries in all other languages support providing custom endpoints:

• C++
• C#
• Go
• Java
• NodeJS
• Python
• Ruby

Describe the solution you'd like

Have an API specifying which endpoint to use.

Describe alternatives you've considered

Additional context

Describe the bug

Bucket names may contain periods, but the BucketName type rejects all strings with periods.

This comment correctly links to these requirements for bucket names. Importantly, bucket names may contain dots (.) - as long as the bucket creator has demonstrated control over the domain containing the bucket name, when the bucket name is interpreted as a domain name.

Note that this means a domain name is always a valid domain name until it hits the API layer (i.e. whenever it's in Rust). I might not be able to create the my-gcs-bucket.embark-studios.com - but it's OK for y'all to create it, or for me to read from it (if/when it exists). That is: within my program('s type system), it's a valid BucketName; it may or may not be valid for a particular API call from a particular user.

To Reproduce

#[test]
fn try_bucket() {
  let bn = BucketName::try_from("my-gcs-bucket.embark-studios.com").unwrap();
}

Seems to be a breaking change from ring 0.16.15 -> 0.16.16

error[E0599]: no method named `description_` found for struct `ring::error::KeyRejected` in the current scope
   --> C:\Users\repi\.cargo\registry\src\github.com-1ecc6299db9ec823\tame-gcs-0.8.0\src\error.rs:162:31
    |
162 |         Error::KeyRejected(re.description_())
    |                               ^^^^^^^^^^^^ method not found in `ring::error::KeyRejected`

Ah was indeed a removal of deprecated functionality briansmith/ring@f06811a

Signed urls are a useful way to get access to data for a limited time that is otherwise private and inaccessible on the general internet.

Implementation details can be found here for the latest version.

We need to upgrade this crate to the recently released 0.2 version of the http crate as that is what the rest of the ecosystem has moved to also with tokio and hyper. Ran into some problems with this crate when testing to upgrade them to the latest git versions

As the http crate is part of the public interface for this crate this requires a 0.x.0 version bump

The release exists on crates.io and was created on commit 599a43c047c6766c7eced76e9374f82cf4b515b7 (not clickable because the commit wasn't pushed):

https://docs.rs/crate/tame-gcs/0.12.3/source/.cargo_vcs_info.json

Is your feature request related to a problem? Please describe.

Currently tame-gcs only exposed API for uploading a file atomically (insert_multipart and insert_simple).

For huge files it is more robust to use resumable upload (insert with uploadType=resumable) to upload the file in chunks.

Describe the solution you'd like

Add a method to support the resumable upload API.

Describe alternatives you've considered

Add a method to support the compose API (or both).

Additional context

Embark uses a standard set of lints across all repositories. We just upgraded
to version 0.3 of these lints, and this repository needs to be updated to
the new set of lints with any warnings fixed.

Steps

1. Copy the contents of the lints.rs file from
   EmbarkStudios/rust-ecosystem and replace the old list of lints in the
   src/lib.rs and/or src/main.rs files with the new list.
2. Run cargo clippy
3. Update and fix any code that now triggers a new warning.

Is your feature request related to a problem? Please describe.
no

Describe the solution you'd like
It looks to me the body of a multipart upload can only be a io::Read, which does not support async reading like the future::AsyncRead. Do you consider supporting it? Thanks.

Describe alternatives you've considered
n/a

Additional context
n/a

Is your feature request related to a problem? Please describe.
Its very annoying to manually implement a copy constructor for enum.
Some of these are very large.

Describe the solution you'd like
Copies of cheap enums should be easy to make.

Describe alternatives you've considered
Creating a large functions that are error prone.

Additional context
Add any other context or screenshots about the feature request here.