Pin redis to 4.1.x, update redis-namespace

What does this MR do?

Required to prep GitLab for moving to Ruby 3.

Changes:

• stricter pin on redis to 4.1.x instead of 4.x (seems safer)
• patch bump redis to 4.1.4 (was: 4.1.3)
  • changes
    • Alias Redis#disconnect as #close. See #901.
    • Handle clusters with multiple slot ranges. See #894.
    • Fix password authentication to a redis cluster. See #889.
    • Handle recursive MOVED responses. See #882.
    • Increase buffer size in the ruby connector. See #880.
    • Fix thread safety of Redis.queue. See #878.
    • Deprecate Redis::Future#== as it's likely to be a mistake. See #876.
    • Support KEEPTTL option for SET command. See #913.
• minor bump redis-namespace to 1.8.1 (was: 1.7.0)
  • changes
    • Allow Ruby 3.0 version in gemspec
    • Fix Redis::Namespace#inspect to include the entire namespaced prefix.
    • Support variadic exists and exists?

Does this MR meet the acceptance criteria?

Conformity

• I have included changelog trailers, or none are needed. (Does this MR need a changelog?)
• I have added/updated documentation, or it's not needed. (Is documentation required?)
• I have properly separated EE content from FOSS, or this MR is FOSS only. (Where should EE code go?)
• I have added information for database reviewers in the MR description, or it's not needed. (Does this MR have database related changes?)
• I have self-reviewed this MR per code review guidelines.
• This MR does not harm performance, or I have asked a reviewer to help assess the performance impact. (Merge request performance guidelines)
• I have followed the style guides.
• This change is backwards compatible across updates, or this does not apply.

Potential risks

I think the riskiest change is the inclusion of https://github.com/redis/redis-rb/pull/880 into the redis 4.1.4 patch release, which a user reported to have increased RSS on their Sidekiq nodes. However, in the issue discussion it turned out to be a red herring and was due to a Sidekiq memory leak instead. But still it's something we should keep an eye on.

I would be odd for a patch release to have a massive impact on client memory use. But then again, it looks like rb-redis interprets semantic versioning pretty loosely; "Support KEEPTTL option for SET command" does not sound like it should be included in a patch release either.

Related to #335197 (closed)