Feature proposal: high integrity mode

[mgravell]

This is a client-library alternative suggestion to redis/redis#13240, to address the issue of protocol desync going undetected for at least "some" commands, and causing mayhem.

Proposal: "high integrity mode"

• new ConfigurationOptions option/connection-string/etc; either a true/false enabled flag, or an int that is "every N messages"?
• adds a correlation identifier (cid) onto every top-level message (probably not inside multi/exec); this could be random or monotonic incrementing (the latter is probably cheaper?) - just opaque bytes used for integrity checking
• adds a hidden echo {cid} or ping {cid} (depending on what is available) before all commands (at least on the interactive connection, probably not needed on pub/sub, but is possible there via ping)
• the cid is verified before processing all responses, burning connections if it ever fails and screaming very loudly
• should possibly focus on the overhauled API - in addition to efficiencies, this already has the concept of "preamble"
• needs performance tuning and impact measurement
• need to document / make enquiries about server cost impact ("do you charge by op? are ping/echo included in that?")

Note that in comparison to the attribute version (redis/redis), this isn't much different at the bytes level:

|1\r\n
+cid\r\n
$10\r\n
1029f737sd\r\n
{actual command here}
...
|1\r\n
+cid\r\n
$10\r\n
1029f737sd\r\n
{actual response here}

vs

*2\r\n
$4\r\n
ping\r\n
$10\r\n
1029f737sd\r\n
{actual command here}
...
*10\r\n
1029f737sd\r\n
{actual response here}

request is 4 bytes larger, response is 10 bytes smaller (vs attribute version)

this has the advantage that it would work on virtually every server version, and could be implemented right now