feat: Option to disable dial on creating client

[SoulPancake]

Approach to #489

[SoulPancake]

Hi @rueian I decided to begin on this However, I have a few doubts about the requirement and have some questions.

1. https://github.com/redis/rueidis/issues/489#issuecomment-1988702413 In this how do we go about testing the last point ( Make sure all the above clients can work after redis is back. ) in a failsafe way.
2. How does the auto-retry work? Do we mean simply returning the structs of these clients without the dial failure being involved like I have done in the current commit? If yes, then how do we update it when the retry is successful?

Thanks in advance. Let me know which direction I can take for this

[rueian]

In this how do we go about testing the last point ( Make sure all the above clients can work after redis is back. ) in a failsafe way.

If you are asking how to write tests for this behavior, I think passing a custom DialFn function, which rejects the first few connections, to the rueidis.ClientOption can help.

How does the auto-retry work? Do we mean simply returning the structs of these clients without the dial failure being involved like I have done in the current commit? If yes, then how do we update it when the retry is successful?

I think, yes, returning their concrete structs is enough except for the sentinel client. The sentinel client may need some modifications to support auto-retry. But for all these three cases, the initial err should also be returned along with their concrete structs.

[SoulPancake]

This has been stale because of other work, so I am closing this now, might re-open a different PR rebasing from latest master @rueian