Cache secrets and concurrent decryption

[travisgroth]

Related to #782 and #444

• Allows concurrent decryption of different secrets files
• Caches decrypted secrets by original file path and returns decrypted results from memory
• Secrets being run through an instance of helmexec will be cached and run as fast as possible concurrently

NB: This particular PR doesn't make all calls to secrets cached and concurrent. Environment Secrets in particular seem to not be evaluated with a ScatterGather(), and doesn't use the same helmexec instance as other parts of the code, so it doesn't take advantage of these changes. Some reworking of the plumbing there would be needed.

[mumoshu]

I think we had a hacky workaround to use helm-secrets for decrypting environment secrets. Perhaps that's one of gotchas? Anyways, I'm fine with just sharing helmexec within and outside of scatterGather, if that works.

[mumoshu]

I read helm.decryptedSecretMutex is for a wider and shorter lock, that is taken until we take a more granular and longer "per-secret" lock. And we now have a in-memory cache of decrypted files paired with mutex's for granular locking, in decryptedSecrets. This does seem to do what it states.

LGTM! Great job. I'm impressed by your work, @travisgroth 🎉 🙏

[travisgroth]

Thanks! Also, your read on the methodology is accurate. Should be least possible lock contention.

I think we had a hacky workaround to use helm-secrets for decrypting environment secrets. Perhaps that's one of gotchas? Anyways, I'm fine with just sharing helmexec within and outside of scatterGather, if that works.

👍 i'm still poking around. I plan on doing some follow up PRs.