Allow SPUBLISH command within multi/exec on replica

[hpatro]

Allow SPUBLISH command within multi/exec on replica

Behavior on unstable:

127.0.0.1:6380> CLUSTER NODES
39ce8aa20f1f0d91f1a88d976ee1926dfefcdf1a 127.0.0.1:6380@16380 myself,slave 8b0feb120b68aac489d6a5af9c77dc40d71bc792 0 0 0 connected
8b0feb120b68aac489d6a5af9c77dc40d71bc792 127.0.0.1:6379@16379 master - 0 1705091681202 0 connected 0-16383
127.0.0.1:6380> SPUBLISH hello world
(integer) 0
127.0.0.1:6380> MULTI
OK
127.0.0.1:6380(TX)> SPUBLISH hello world
QUEUED
127.0.0.1:6380(TX)> EXEC
(error) MOVED 866 127.0.0.1:6379

With this change:

127.0.0.1:6380> SPUBLISH hello world
(integer) 0
127.0.0.1:6380> MULTI
OK
127.0.0.1:6380(TX)> SPUBLISH hello world
QUEUED
127.0.0.1:6380(TX)> EXEC
1) (integer) 0

[soloestoy]

There are two issues:

1. Whenever a transaction contains shard pubsub commands, the entire transaction is considered as is_pubsubshard, which is too broad of a scope. Although it may not have any practical impact at the moment, there is a potential risk. Perhaps we should rename the variable to include_pubsubshard.
2. Non-shard pubsub commands, such as publish/subscribe, are also marked as CMD_PUBSUB, which leads to incorrect determination of publish/subscribe in transaction as is_pubsubshard. Although it may not have any practical impact currently, there is a potential risk.

[hpatro]

Thanks for the feedback @soloestoy.

Agree for point 1, will update it.
I did think about point hence the comment. Explicit command matching across multi command would be slightly painful and introducing a new command type felt unnecessary at this point. Do you think it's reasonable to continue with the current implementation.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[sundb]

A new PR has been created based on the commits from this PR. Please refer to #13276 for the latest updates and discussion.