AP-5015 extend redis config sanitization

[kjamrog]

Changes

• Adds maxRetriesPerRequest: null parameter to RedisConfig sanitization
• Adds createSanitizedRedisClient utility method for creating bullmq compatible redis client

Checklist

• Apply one of following labels; major, minor, patch or skip-release
• I've updated the documentation, or no changes were necessary
• I've updated the tests, or no changes were necessary

[kjamrog]

In some places we will still want to operate on Redis instance, not on config, while taking advantage of sanitization step. Therefore I think it's useful to have function that allows to create such instance. Let me know if you disagree

[kibertoad]

we don't have a factory per se here, just a one-liner wrapper.

what is the added value on top of the sanitizeRedisConfig method? Can't user apply sanitizeRedisConfig on their own when creating a new instance?

I'm not against having it, primarily not convinced that it deserves a separate file. can be just part of utils

[kjamrog]

Initially I added it as a part of utils, but those are internal and not exported, so finally decided to put public one in separate file. I noticed in UPGRADING.md that with recent version sanitizeRedisConfig was explicitly excluded from public ones, not sure why.
But I can put it back to utils and export that one function if you think it's better, no strong opinion from my side

[kjamrog]

Regarding sanitizeRedisConfig - sure, it could be exported and used as well, I was just thinking that if it's always used just for new Redis(sanitizedConfig), we can already have it wrapped. Also no strong preference :)

[kibertoad]

I would be in favour of exporting the sanitization method, but also I'm not against having a separate method for instantiation, we can have both

[kjamrog]

Moved it to utils and exported those 2 metrics

[CarlosGamero]

Stupid question, but where will we use this? just wondering if we need this exposed

[kjamrog]

One example is in fastify-extras, we have 2 queue discoverers there: one uses backgroundJobProcessorGetActiveQueueIds from background-jobs-common, another one operates directly on redis instance, and there we could still benefit from sanitized instance instead of creating one with new Redis.

Also, in Flow, we always create Redis manually from config, like: new Redis(redisConfig). I think in the follow up PR's we could replace it with createSanitizedRedisClient to ensure that required properties are always there.

Does it make sense?

[CarlosGamero]

For Fastify extras, I agree completely and it makes a lot of sense.

On Flow side, I am not sure if we want to sanitaise redis config, it is a requirement for BullMQ and the library is already taking care that those connections are sanitized, I think Flow should decide on those parameters base on needs