Enable client-side caching

[bifurcation]

Having the extension_data of the client extension be empty is wasting an opportunity. Instead, we should allow the client to maintain a cache of RRs it has seen for each server, and then have the client tell the server in its ClientHello what RRs it still has and considers valid.

[MelindaShore]

Viktor's comments on client-side caching:

"Validation of RRSIGs is a subtle art, the client will definitely need to check not only the signatures but also the validity intervals of all RRSIGs (the client must trust its own clock or have access to a trusted time source). Since the server forwards wire-format RRsets, these include TTLs, and clients might plausibly cache these, provided the TTLs are consistent with the RRSIG validity intervals. The draft might provide guidance on any client-side caching (clients might e.g. not even send the extension when they have unexpired cached TLSA data from a previous interaction with the server)."

[shuque]

Right now the document says clients don't cache (I think mainly to reduce implementation complexity on the client, was our original thinking), so we'll need to adjust.

I'll add a placeholder that a future revision of the doc will allow clients to cache and send a list of cached, unexpired records in the extension. The security considerations section also needs to be rewritten a bit. There are several things not quite correct in it, but the current description about caching specifically is incorrect (it says no caching at all, whereas the server was already expected to cache and reuse the chain).