add some redis client config that may be commonly used

[Taction]

Description

add some config that can be set from metadata for redis client.

Issue reference

Checklist

Please make sure you've completed the relevant tasks for this PR, out of the following list:

• Code compiles correctly
• Created/updated tests
• Extended the documentation / Created issue in the https://github.com/dapr/docs/ repo: add pubsub redis config docs docs#1334

RELEASE NOTE: Added commonly used Redis client settings

[ghost]

All CLA requirements met.

[pkedy]

I love seeing more connection settings coming in this PR! I'd like just a few changes for consistency with the duration-based settings.

[pkedy]

@Taction Thanks for all your work on this. I know there have been a few iterations now. Two things:

1. Before this can be merged, there should be an open PR in dapr/docs to update this page with the new settings. Make sure branch from and target the v1.1 branch in the PR. Its easy to forget.

2. I think I have steered you in the wrong direction with the settings naming but wanted to ask your opinion.

Context: In v1.2 we'll likely be adding more backoff settings to some of the pubsub components. The backoff/retry library we are using handles retries between the sidecar and the application.

Where I steered you wrong: All the settings I had you prefix with backOff are actually between the sidecar and Redis itself. Correct? If that is the case a different prefix should be used. Maybe read? I'm not actually sure where exactly these settings come into play in the client module but I'm assuming its for any CMD call. WDYT?

[Taction]

@Taction Thanks for all your work on this. I know there have been a few iterations now. Two things:

1. Before this can be merged, there should be an open PR in dapr/docs to update this page with the new settings. Make sure branch from and target the v1.1 branch in the PR. Its easy to forget.
2. I think I have steered you in the wrong direction with the settings naming but wanted to ask your opinion.

Context: In v1.2 we'll likely be adding more backoff settings to some of the pubsub components. The backoff/retry library we are using handles retries between the sidecar and the application.

Where I steered you wrong: All the settings I had you prefix with backOff are actually between the sidecar and Redis itself. Correct? If that is the case a different prefix should be used. Maybe read? I'm not actually sure where exactly these settings come into play in the client module but I'm assuming its for any CMD call. WDYT?

@pkedy :

1. For the second thing, I know what you actually want to tell me. I've seen the use of backoff options in mqtt component which is used for handle retries between the sidecar and the application.But there are lots components do not have these options so I didn't catch the point at that time. And I should have confirmed with you about it.

As for the prefix, is redis a better choice（such as redisMaxRetries）? As far as I'm concerned it may have 2 potential advantage. One is that it may be more easily for users to tell these options apart from backOff options, as the name may shows that it is for redis configuration. Two is that read is a more general expression, if some other components have similar option between client and server read may be a better choice(I am not very familiar with other components now, so i assume that there is not much components whit these option).

2. For the first thing,I will work on this but it will take me some time to finish it. And It is very kind of you to stress out what is easy to forget.

What's more, in my opinion both read and redis is fine for the prefix. Which one do you think is more suitable?

[pkedy]

@Taction

For 1, the backOff* settings are slowly being added to the components starting with the ones that really really need it (e.g. Kafka). Also, backOffMaxRetries is only setting for now but more settings are one their way maybe in 1.2.

For 2, I think we are in agreement! redis or read is fine as a prefix. As the author of this PR, I'll let you decide between the two. :) I just wanted to avoid backOff in this case because its for a different point in the call chain. Again-my mistake for steering you that way to begin with and thanks for your understanding. Once you make that change, we can finally get this merged unless @artursouza has other comments.

Also, please mention the docs PR in this PR or visa versa. Thanks!

[artursouza]

@Taction

For 1, the backOff* settings are slowly being added to the components starting with the ones that really really need it (e.g. Kafka). Also, backOffMaxRetries is only setting for now but more settings are one their way maybe in 1.2.

For 2, I think we are in agreement! redis or read is fine as a prefix. As the author of this PR, I'll let you decide between the two. :) I just wanted to avoid backOff in this case because its for a different point in the call chain. Again-my mistake for steering you that way to begin with and thanks for your understanding. Once you make that change, we can finally get this merged unless @artursouza has other comments.

Also, please mention the docs PR in this PR or visa versa. Thanks!

LGTM

[pkedy]

@Taction To @mukundansundar 's point in your docs PR, we need an issue created as this is a pretty good sized enhancement. We do this for tracking things int the RELEASE NOTES.

[codecov]

Codecov Report

Merging #763 (22b475e) into master (c1905ba) will increase coverage by 0.08%.
The diff coverage is 37.96%.

@@            Coverage Diff             @@
##           master     #763      +/-   ##
==========================================
+ Coverage   32.78%   32.86%   +0.08%     
==========================================
  Files          97       97              
  Lines        8744     8847     +103     
==========================================
+ Hits         2867     2908      +41     
- Misses       5616     5649      +33     
- Partials      261      290      +29     

Impacted Files	Coverage Δ
pubsub/redis/redis.go	28.67% <37.96%> (+6.26%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update c1905ba...22b475e. Read the comment docs.

[pkedy]

@Taction I added RELEASE NOTES to the description of this PR which our release process also picks up. So in the interest of moving this along, no need to create an issue. Just know for the future that large changes need an issue.