IAM: Add caching to HTTP client

[reinkrul]

Fixes #3142

@woutslakhorst @gerardsn is this an approach you agree on?

I think the Nuts node should having client-side caching features on board, since I've not often seen an outbound proxy, let alone one that performs caching. So I suspect most parties won't be considering an outbound proxy for caching capabilities. This could severely downgrade performance/UX, given how often the same resources are requested.

There are a few libraries that do this, but all of them were archived and unmaintained with reasons like:

• This is so easy to implement, no need for a library
• Caching is not needed in modern architectures (?)
• Caching is very application-specific, so a library is too hard/complex/big

This solution just looks at expiry time (typically max-age), keeps cached resources around for max. 1 hour (or max-age if less). It also maxes out the available cache to 1mb (ofc. should be configurable).

[woutslakhorst]

Also add an issue for adding metrics to the client cache for hits vs misses. (enterprise feature ;))

[woutslakhorst]

For readability purposes place a single lock/unlock at the beginning of the only public method.

[reinkrul]

That causes IO to be included in the lock scope, so that causes scalability/performance issues. I refactored the function a bit to make it seem less random.

[gerardsn]

out of interest / sanity check; how many simultaneous requests (order of magnitude) do you think it takes before the mutex is slower than ignoring cache? A successful authorization_code flow locks around 15-20 for the verifier and for the requester/holder

[reinkrul]

out of interest / sanity check; how many simultaneous requests (order of magnitude) do you think it takes before the mutex is slower than ignoring cache? A successful authorization_code flow locks around 15-20 for the verifier and for the requester/holder

Locking is only done while checking whether there's a cached copy and when inserting an item into the cache (memory/CPU operations only), not during HTTP requests/IO. So caching with mutexes will be much, much faster than performing HTTP requests, even with many parallel connections (I'd say especially with many parallel connections).

[reinkrul]

@woutslakhorst I noticed the did:web resolver calls weren't cached, since it creates its own HTTP client (through core.NewStrichtHTTPClient(). I moved the strict HTTP client to the http/client package so we can manage the caching HTTP client centrally.

v5 functionality does not use the caching HTTP client.