Router planning for modify queries fails to detect shard replication factor mismatch

[onurctirtir]

And that causes some modify queries to fail very late because we think that it's router planneble.

SET citus.shard_replication_factor TO 1;

create table single_shard_dist(a int, b int);
SELECT create_distributed_table('single_shard_dist', 'a', shard_count=>1);

SET citus.shard_replication_factor TO 2;

CREATE TABLE distributed_table(a int, b int);
SELECT create_distributed_table('distributed_table', 'a', shard_count=>4);

WITH cte AS (
    DELETE FROM distributed_table WHERE a = 1 RETURNING *
)
SELECT * FROM single_shard_dist WHERE b IN (SELECT b FROM cte);
ERROR:  relation "public.single_shard_dist_102008" does not exist
CONTEXT:  while executing command on localhost:9702

Making router planner colocation aware (#692) would automatically fix this too.

[onurctirtir]

#6793 (comment):

Even more, allowing such queries to go through router planner also causes
generating an incorrect plan for the DML queries that reference distributed
tables that are sharded based on different replication factor settings. For
this reason, #6779 can be closed after altering the default value for this
GUC to "false", hence not now.