THREESCALE-8404: Bump redis to 5.2.0

[jlledom]

This comes from https://github.com/3scale/apisonator/pull/350. That PR is too big, it has a lot of outdated info and so many comments and commits it could lead to confusion. I decided to split it into smaller PRs easier to review and understand.

This PRs updates the redis gem to 5.2.0 but it doesn't include any new functionality compared to master.

Commits:

• https://github.com/3scale/apisonator/commit/5125eed61e7f71be67b54712aab7f88784876ba1: It updates the Gemfile and fixes some breaking changes.
• https://github.com/3scale/apisonator/commit/9fe39fe2acf17a14e48c34fdd322b7f5c56ee5eb: Updates some calls to the redis API that changed in redis 5. In particular :sadd?, :srem?, :exists? and :pipelined.
• https://github.com/3scale/apisonator/commit/d80612315dc0876686c2802d425a84500bcb7dea: The new API requires some major changes in the async client. For instance, a new implementation of the pipeline logic.
• https://github.com/3scale/apisonator/commit/640a5e4ea756cb61fa5432feb32fa613de851c1f: Update tests.

[jlledom]

This comes from https://github.com/3scale/apisonator/pull/350#pullrequestreview-2053678308

IIRC, when @fetch_timeout is reached, the method will return nil, not raise. A read timeout on the other hand is a low-level TCP timeout that shouldn't happen regularly.

On the other hand, we don't need to be very much bothered by a connection timeout, if we can just reconnect. It's good to be resilient in case of network glitches.

I would suggest though to log the error, can be without a trace, just dome text like:

Que redis (ip/hostname of server if possible) connection timeout at #{FILE}:#{LINE}

In this way we can have an indication of network stability and see whether particular servers or locations are more problematic. This will help debugging and improving the cluster setup.

@akostadinov You're right, the docs say it should return nil, however it raises an exception when connecting to sentinels. I opened an issue upstream to fix it: https://github.com/redis/redis-rb/issues/1279

In the meantime we must capture the exception. And I don't think we need to log it because it would flood the logs with this error happening all the time, since it's the expected behavior.

[jlledom]

From https://github.com/3scale/apisonator/pull/350#discussion_r1599011490:

Why can provider key be nil? Should we conditionally add or should we raise an error?

@akostadinov I honestly don't remember why I did this, and it indeed looks wrong. I'm removing this line for now, let's see if something breaks.

[jlledom]

From #350 (comment):

Why can provider key be nil? Should we conditionally add or should we raise an error?

@akostadinov I honestly don't remember why I did this, and it indeed looks wrong. I'm removing this line for now, let's see if something breaks.

@akostadinov I found why I did it. It's because some tests fail. redis-rb 5 doesn't accept nils as parameters for it's redis calls, only strings. However, I think it's the tests what were wrong, not the code. I pushed some changes (https://github.com/3scale/apisonator/pull/384/commits/b4c0c8788a21526d54377679c8933b9a39f35f31)

[mayorova]

Looks good @jlledom great job! :clap:

I'm just concerned about that change with the provider_key in tests. Otherwise, all looks nice.