Add bitfield api

[rubicon0501]

Just add bitfield api

[sewenew]

Thanks for the contribution!

However, it seems that the bitfield interface you proposed, is not more user-friendly than the generic interface: command method:

std::vector<std::string> ops = {"bitfield", key, "SET", "u1", "1", "1","SET", "u1", "3", "0","SET", "u1", "6", "1"};
redis.command<optional<vector<opitonal<long long>>>>(ops.begin(), ops.end());

I checked the doc on redis.io, this command, which has 3 subcommands, is quite complex. It seems that there're 2 solutions:

1. Encapsulate subcommand into a struct, and pass STL container of this struct as parameter for bitfield:

struct BitFieldSubCommand {
    enum class BitFieldOp {
        GET,
        SET,
        INCR
    };
    std::string encoding;
    long long offset;
    long long value;
    enum class OVERFLOW {
        WRAP,
        SAT,
        FAIL
    };
    OVERFLOW overflow = WRAP;
};

template <typename Input, typename Output>
void bitfield(const StringView &key, Input first, Input last, Output output);

// Usage:
vector<BitFieldSubCommand> subcommands = {BitFieldSubCommand{}, BitFieldSubCommand{}};
redis.bitfield(key, subcommands.begin(), subcommand.end());

2. Make each subcommand as a container of strings:

template <typename Input, typename Output>
void bitfield(const StringView &key, Input first, Input last, Output output);

// Usage:
vector<vector<string>> subcommands = {{"set", "i4", "10"}, {"get", "i4", "10"}};
redis.bitfield(key, subcommands.begin(), subcommand.end());

However, both solutions are not perfect. The first one is a little complicated, and the GET subcommand doesn't need the value and overflow members. The second is also not more helpful than the generic command interface.

Not quite sure which solution is the best one. Or maybe for complex command, the generic command is the best choice?

B.T.W. you should save the return value of bitfield into a STL container of type optional<long long>, instead of long long. Because if the OVERFLOW type is FAIL, the return value might be nil reply.

Regards

[rubicon0501]

@sewenew Thank you for reviewing.

[rubicon0501]

In fact, redis-plus-plus can implement almost all commands through the generic interface: command method, I just want to add the api of bitfield to the project with minimize the use of command, I think it looks more perfect. The first solution of your reply is really too complicated, and the second is better than mine, because it uses type optional<long long>, instead of long long. They all support passing each subcommand as a container of strings. I use this usage because Jedis use this format, so people who have used Jedis before will adapt better.

If you think use command directly is better, we can close the pull request.

[sewenew]

Thanks for the info on Jedis! Let's make this PR pending to see if there're any new feedback from others. Also I'll take a look at other client APIs for these complex command.

Regards