fix: protocol out of sync when mixing sunsubscribe requests and slot migrations

[rueian]

Fixes #690

In the TCP dumps provided by the issuer, we found the following traces during slot migration:

1. client -> [SUNSUBSCRIBE channel1] -> server
2. server -> [sunsubscribe channel1] -> client
3. client -> [HGET key field] --------> server
4. server -> [MOVED slot address] ----> client
5. server -> [True HGET response] ----> client

In the above sequence, (2) was the proactive sunsubscribe message sent by the server due to slot migration, and the message was wrongly delivered to the (1) SUNSUBSCRIBE request sent by the user. The true response to the (1) should be (4), the MOVED.

The wrong delivery of (2) caused the pipeline out-of-sync. The (4) MOVED was also wrongly delivered to (3), the HGET request. Then finally the (5), the true response of the HGET, couldn't be delivered anywhere, thus the pipeline panicked.

This situation is the same as valkey-io/valkey#1066.

Workaround

Ideally, we need to differentiate whether the server sent those sunsubscribe messages due to slot migration, but it is impossible. Our only choice is to ignore all sunsubscribe messages and make a dummy response for the SUNSUBSCRIBE request. Besides SUNSUBSCRIBE, we also apply this method to all *UNSUBSCRIBE so that we don't need to keep track of how many channels and patterns the client has subscribed to.

1. We ignore *unsubscribe messages while delivering messages to requests.
2. We make up responses for *UNSUBSCRIBE requests by injecting a PING request after each *UNSUBSCRIBE.
3. If a *UNSUBSCRIBE request succeeds, then the PONG response will be delivered to it.
4. if a *UNSUBSCRIBE request fails, such as MOVED or CLUSTERDOWN, then the error will be delivered to it, and the following PONG response will be discarded.

If the injected PING failed with a NOPERM error, we treat it as a normal PONG response.