Add optional LocalCache storage tier for certificate assets

[mbardelmeijer]

Certificates are loaded from Storage during handshakes whenever the in-memory cache misses, which is slow when Storage is remote. This adds an optional Config.LocalCache Storage that sits between the two: reads that serve certificates are answered locally, while the operations that coordinate with the rest of the cluster (renewals, issuance, and reloading a certificate a peer renewed) read Storage directly and refresh the local cache with what they read. Writes and deletions go to Storage first, then to the local cache; locking is never local.

Callers pick between the two with cachedStorage and groundTruthStorage. Certificate, key, and metadata files and OCSP staples all go through the same path. WarmLocalCache pre-populates the local cache for a subject without touching the in-memory cache or doing any certificate operations.

The field is nil by default, so behavior is unchanged when it is unset.

Build with Claude Opus 5

If the direction of this PR is good/workable, I'm happy to run some field tests with it.

[mholt]

Hey, thank you. I think this is good, if it is working well for you.

My only question would be is if there's a failure mid-write, since Storage doesn't provide atomic writes for multiple files, I wonder if we should have a recovery plan:

• If the cached certificate and key fail to parse or match, retry the complete resource once using groundTruthStorage().
• That retry naturally overwrites the local entries with authoritative values.
• Add a test with an old cached key and a renewed authoritative certificate/key.

What do you think?

Thank you for the contribution!