upgrade lettuce and fix deprecation warning

[yisraelU]

No description provided.

[bpholt]

Since this was a major version update to lettuce, should merging this have triggered a major version update to this library? (I think if the bincompat surface didn't change, it's probably fine either way, but I think they did remove some deprecated methods, so it seems risky to me?)

[yisraelU]

@bpholt I'm not sure whats accepted practice.
The goal of this library is a wrapper and our surface preserves binary compatibility . On the other hand , there is a unsafe api call that exposes the underlying Lettuce api

[satorg]

@yisraelU , sorry for jumping into the conversation, but since the underlying library is not fully enclosed, according to semantic versioning principles, it would be safer to bump up the major here too. Moreover, given that #1079 introduces binary incompatibilites as well, I'd suppose that upgrading the major is the way to go for the next release.

[mmienko]

Version bump is reasonable in this situation. There’s the unsafe api and all the connection builders which take Lettuce builders and options.

[yisraelU]

okay, I think it's a bit of a gray area but definitely makes sense . I'll add a warning to the release that contains the breaking change of the underlying library.
Going forward, I'll open a series/3.x branch where we can open PR's against and potentially aggregate all other binary breaking changes.

[yisraelU]

Rollbacked here #1082
Will create new release and mark old release do not use