feat(response-ratelimiting): add support for secret rotation with redis connection

[bungle]

Summary

Adds support for secret rotation for redis credentials in response-ratelimiting plugin.

[hbagdi]

Aapo, was the plan not to keep this transparent to the plugin authors and resolve the referenced username/password before calling any plugin handler code?

I'm surprised to see this code here.

[bungle]

@hbagdi, this is the resolve-secret-on-failure approach. Most of the cases we have with secrets are resolve-on-secret-failure. But we decided to focus on more generic ttl, but that has limitations. E.g. with try, you can just go to vault and change secret and then change db password, and Kong should be able to pick it up. The TTL approach requires a more coordinated approach. That is when rotating, you should keep the old one at least for TTL amount of time, and after that you may drop the old credentials. The TTL approach can be seen in action here (the update function): 83bd52b

But the TTL we currently only re-resolve secrets only every minute as most:
20c2da8#diff-212b3488c5eb070820f7bc5178fbaa56e9435fe49cf050feb29091ca9aa1540bR49

There is no way to do fail-and-resolve anywhere else than where the failure happens.

[oowl]

@bungle I have seen this PR was added to 3.3 milestones, And the code looks Okay. Why was this PR labeled draft?

[bungle]

Moving this to 3.4, and perhaps abstract it a bit more.

[kikito]

I'm going to remove this from the 3.4 milestone. We are too busy fixing the bugs we found on the "regular" (non-try-based) TTL code to expand the scope even more. Also, this PR has no tests.

[kikito]

I'm approving this because (request-)ratelimiting has the same change and otherwise this would make both plugins iconsistent.