Support in-memory caching of secrets

[WillDaSilva]

Current Behavior

Currently calls to Resolve always result in the 1Password API being used, even if the same reference is given multiple times in a row.

Desired Behavior

In some cases the current behaviour fine, but if an item in 1Password has many fields, and needs to be resolved many times, this is result in excessive redundant API calls, resulting in poor performance, and rate limiting.

We could add an optional parameter to the Resolve function to control caching. By default, the current behaviour (no caching) would be preserved. There are many ways that caching could be implemented, and I won't outline them all here before knowing if there is any interest by the maintainers in this feature.

For my use-case I'd be most interested in a per-client in-memory cache with manual eviction (i.e. no TTL or LRU + max size behaviour). This would be simple to implement, but not entirely simple to use for long-running programs that continuously use the same client. In my case the program is not long-running, so there's no worry that the cache will grow too large.

Benefits & Value

We expect that if this were implemented, then we could update https://github.com/helmfile/vals to use the cache, which would shave a few minutes off of each of our deployments, and substantially reduce the number of API calls we make to 1Password. This would help us avoid the rate limit, which has caused us an outage in the past.

Additional information

A workaround we are considering is implementing a proxy between the program using the 1Password SDK, and the 1Password API, and then implement the caching in the proxy. This is made difficult due to TLS.