[ENHANCE] Re-evaluate using hashes to store secrets for comparisons during upgrade

[MuneebAijaz]

Is your feature request related to a problem? Please describe.
As of now, reloader converts secrets into a hash, and stores it in a deployment as an env variable, which then triggers an upgrade in underlying pods.

This causes two concerns

1. for normal usecases of upgrades, we dont need to compare the hashes, informers can directly watch the secrets and do the comparison for us
2. currently, sha1 is used, which becomes a security concern
3. upgrading to a safer encryption might bring reloader under more computational load

Describe the solution you'd like
For the solution,
We can use informers for simple comparison usecases when both old and new instances of secrets are available.

For edge cases,

• when the watched secret is recreated, we want to compare the old instance and new instance to see if the secret has been changed, and only then we will trigger upgrades. For this, we can use a safer hashing algorithm, and since this edge case will rarely hit, we wont have additional computational load most of the time because of this.

Describe alternatives you've considered
Not yet, open for discussion

Additional context
Add any other context or screenshots about the feature request here.

[fdberlking]

Related issues regarding SHA1: #594

Related PR: #527