[LukeKennedy]

What

This change adds RFC 0004, proposing a configuration to add a secondary plaintext listener for DynamoDB APIs. Management and metrics endpoints are excluded from plaintext operations. To restrict use of the plaintext endpoint, the aws:SecureTransport key has been added to enable IAM level control of users access to the plaintext and TLS endpoints.

Why

ExtendDB requires TLS on its only listener. That is the right default, but it blocks a common deployment pattern: terminating TLS outside the process. Operators deploying ExtendDB behind a load balancer (AWS ALB with TLS listeners, nginx, HAProxy) or inside a service mesh (Istio, Linkerd, Consul Connect, ECS Service Connect) want the proxy to own certificates, rotation, and mTLS, and forward plaintext HTTP to the backend over a link they already trust (inside a pod, a private subnet, or a mesh sidecar).

Checklist

• [ x ] I have read CONTRIBUTING.md
• [ x ] All tests pass (cargo test --workspace)
• [ x ] Code is formatted (cargo fmt --check)
• [ x ] Clippy is clean (cargo clippy -- -W clippy::pedantic)
• [ x ] I have added or updated tests for new functionality
• [ x ] I have updated documentation if behavior changed
• [ x ] Breaking changes are noted below (if any)
• [ x ] If this changes the wire protocol, Storage trait, auth model, on-disk
  format, or public CLI surface, an RFC has been accepted or is linked
  below. Otherwise, an ADR captures the decision (link below).

ADR / RFC: This is the RFC.

Breaking changes

n/a

---

By submitting this pull request, I confirm that my contribution is made under
the terms of the Apache License 2.0 and I agree to the Developer Certificate of
Origin (DCO). See CONTRIBUTING.md for details.

[jmayclin]

One additional lens: there is no longer "one right" TLS configuration. To enable ExtendDB to meet multiple customers requirements, either ExtendDB must support multiple distinct TLS configuration, or allow for customers to front ExtendDB with their own proxy.

One example of mutually exclusive TLS configuration is with PQ configuration. Some compliance requirements like CNSA 2.0 strictly require pure PQ key exchange (MLKEM1024). Other compliance requirements - and most of the industry - prefers hybridized PQ key exchange (X25519MLKEM768).