Core signs requests to AWS #1338

One of the removals listed in #777.

What is wrong

crates/trusted-server-core/src/s3_sigv4.rs signs asset route reads and the publisher origin's reads with AWS Signature Version 4, and [publisher] origin_auth and the asset routes' settings know the s3_sigv4 form with its access key and secret. So core knows one cloud vendor's signing scheme and its credentials, and an origin that wants another scheme, or signed reads from another vendor's storage, has to add a branch to core.

What changes

• Core keeps an origin authentication interface. origin_auth selects by name a module that signs an origin request, given the final address and host after any rewrite, and core calls it where it signs today.
• AWS signing is a shared vendor crate. The signer and its settings go to crates/shared/aws, as what a vendor offers to every crate that wants it, so the object storage origin (The publisher origin can be a folder of signed object storage #1329), the asset routes and any module that reads from that vendor's storage sign through one crate.
• The settings keep their shape. origin_auth = "s3_sigv4" with its keys reads as it does today, from the module's own table, and a name nothing supplies is refused at startup with the names that could be written.

Why

A signing scheme is a vendor's, and core offers the neutral interface a signer implements. The object storage origin came into the stack signing through core's one scheme because that was where the scheme lived, and this moves it to where it belongs.

What breaks

Nothing for a deployment whose build links the AWS crate, which the stock adapters do.

Where it is

A series on the stack, as a draft on the fork, jwrosewell#43, on top of the backend naming series (fork pull request 42).