Optimize cross-shard routing for UPDATE/DELETE queries with IN clauses

[aquarapid]

In #6116 we optimized shard targeting for IN clause statements providing a vindex key. However, unlike for SELECT statement, we do not optimize the actual content of the IN clause during the scatter.

An example:

SELECT optimizes the IN clause as well as optimizes the targeting:

+ vtexplain -schema-file schema.sql -vschema-file vschema.json -shards 8 -sql 'select * from bar where c1 in (1,2,3,4)'
----------------------------------------------------------------------
select * from bar where c1 in (1,2,3,4)

1 ks1/-20: select * from bar where c1 in (1, 2) limit 10001
1 ks1/40-60: select * from bar where c1 in (3) limit 10001
1 ks1/c0-e0: select * from bar where c1 in (4) limit 10001

----------------------------------------------------------------------

UPDATE just optimizes the targeting:

+ vtexplain -schema-file schema.sql -vschema-file vschema.json -shards 8 -sql 'update bar set c2=1 where c1 in (1,2,3,4)'
----------------------------------------------------------------------
update bar set c2=1 where c1 in (1,2,3,4)

1 ks1/-20: begin
1 ks1/-20: update bar set c2 = 1 where c1 in (1, 2, 3, 4) limit 10001
1 ks1/40-60: begin
1 ks1/40-60: update bar set c2 = 1 where c1 in (1, 2, 3, 4) limit 10001
1 ks1/c0-e0: begin
1 ks1/c0-e0: update bar set c2 = 1 where c1 in (1, 2, 3, 4) limit 10001
2 ks1/40-60: commit
3 ks1/-20: commit
4 ks1/c0-e0: commit

Obviously this isn't a functionality issue; but it does avoid unnecessary key lookups on each shard backend instance.