Changes to outbound redis interfaces

[rylev]

Part of #1866

The changes to the interface are:

• Uses a connection oriented resource rather than free functions.
• Updates the error type from just being error to 4 different error possibilities.
• Moves the functions that returned to s64 to return u32 since they should never return anything by positive numbers
• get returns result<option<list<u8>>, error> rather than result<list<u8>, error> returning ok(none) when the key does not exist - this mirrors how Redis's server API.

[rylev]

In #1866 I said we should change get to return option so that it would return ok(none) if the key is not set. However, the underlying redis crate returns an empty Vec if it sees nil. Should we continue to propagate that behavior or should we return option? The current behavior may be surprising to those familiar with the redis API.

[lann]

Looks like the underlying get can return any FromRedisValue, which could be an Option<Vec<u8>> to preserve the nil: https://docs.rs/redis/latest/src/redis/types.rs.html#1516

[rylev]

@lann my question isn't how to make it work but rather what should the API be? Is it better to mimic the way the redis crate works or is it better to be more true to the underlying redis API?

[lann]

Unless I'm missing something, the underlying redis API supports both, depending on whether your call to get uses RV = Vec<u8> or RV = Option<Vec<u8>>. It is just our current implementation that (implicitly, via inference) uses RV = Vec<u8>.

I assume this is the trait method being called: https://docs.rs/redis/0.23.3/redis/trait.AsyncCommands.html#method.get

[lann]

Sorry, I misread/misinterpreted what you were saying.

I think get should either return none or an error (e.g. no-such-key). Probably would lean toward an option especially since this is a behavior change.