I understand now, but I'm not sure it's well fit to some place it's used. For website configuration, if two updates happen at the same time, I think it makes more sense to consider an arbitrary one…
I find this implementation surprising. I'd expect Some(true) and Some(false) to be merged to Some(true), not None.
allow_owner is not merged. Is it sementically read-only hence don't needs to (if so, please document it), or just forgotten?
I'd argue only website_config should exist, with a Some(_) generated automatically when migrating from 0.5 with website enabled.
can't this pose problem if someone create a bucket which name is hex of the right size?
I think this link could be one line lower to only cover the "offending" function
there is a .get_bucket() on Endpoint which can be used to do the same thing more concisely
first round of review (up to model sub-crate, I did not get the time to go further).
instead of recalculating the signing key from date, secret_key and region each time, couldn't check_streaming_payload_signature take the precomputed signing key? It would cut down on parameters/fieds here and in SignedPayloadChunker, and be (negligeably) faster due to less hmac computation