Add support for node-redis v4.0.0 and newer

[aardvarkk]

• Fixes Caching with Redis broken with Redis v4 #8420
• v4.0.0 and newer of node-redis will no longer auto-connect, so we need to add that step
• For backwards compatibility, we check for the existence of a "v4" property so we don't try to call connect on older versions of the client
• A legacyMode flag exists in the new v4.0.0 of node-redis to keep a similar calling style without having to change any code
• This option can be passed via the createClient options, so I've added documentation to indicate that this is required if users would like to use v4.0.0 of node-redis
• Note that the legacyMode flag is required to be passed if the calling code isn't going to be changed

Description of change

Pull-Request Checklist

• Code is up-to-date with the master branch
• npm run lint passes with this change
• npm run test passes with this change
• This pull request links relevant issues as Fixes #0000
• There are new or updated unit tests validating the change
• Documentation has been updated to reflect this change
• The new commits follow conventions explained in CONTRIBUTING.md

[aardvarkk]

I'm realizing approach that could be done here is to force legacyMode to be added on createClient options if v4 is detected -- that way we wouldn't need to tell/remind users in the docs that they also have to pass this option to get it working properly. But it would require a slightly more aggressive patch, so I opted for the most minimal change at this point.

[pleerock]

But it would require a slightly more aggressive patch, so I opted for the most minimal change at this point.

What are the downsides of this aggressive approach? Does it bring any user-facing issues? If no, we can simplify user experience.

[aardvarkk]

@pleerock I see there being at least four possible ways to fix this:

1. What I've done so far in this PR, which requires the smallest change in the TypeORM code but requires the user to pass a legacyMode flag.
2. Automatically passing legacyMode as an option if redis v4 is detected. This would require a slightly heavier-handed change to TypeORM, but would probably eliminate a class of errors where users forget to pass legacyMode themselves and wonder why it's not working.
3. Rewriting the TypeORM code to be promise-based and require redis v4. This would eliminate the need to pass any legacyMode flag. But it would probably cause a lot of problems for people who are still using/dependent upon v3 of redis if they're also using the package themselves.
4. Split the Redis caching implementation in two: one promise-based and the other callback-based. Both node-redis and ioredis support both styles, I believe. This would be the most flexible in that would still support v3 and v4 without having to pass any additional flags, but would require a fair amount of new code and also add more "surface area" to the Redis caching implementation as possible sources of bugs.

I'm happy to adjust this PR to move from implementation approach 1 to approach 2 if you believe that approach to be superior. I don't believe it would impact users directly and would remove the need for them to pass legacyMode themselves.

[aardvarkk]

I've updated the code to obviate the need for a client to pass legacyMode themselves, but haven't tested it out locally yet.

[aardvarkk]

@pleerock I've done my local testing and checked that:

1. legacyMode: true is ignored by v3 and so it has no effect to pass regardless of the version
2. We only try to call connect() if the property exists within the Redis client, which it doesn't prior to v4. I liked this approach better than looking for "v4" as I was doing previously, because presumably what I have now could extend to a v5 if that ever happened.
3. This setup appears to work with and without specific cache options being passed both in v3 and v4.

Please let me know if there's anything else you need in regard to this PR.

[pleerock]

Thank you for contribution! 🎉

[meronogbai]

@pleerock I need to update node-redis to v4 on a production application and I was wondering when this fix will be released to npm.