SELECT ... FOR UPDATE is routed to REPLICA

[to2016]

If you have a PostgreSQL cluster with one leader and replicas the SELECT ... FOR UPDATE is routed to REPLICAS.
This is a problem because it is not possible to set the LOCKS for it on a REPLICA.
SELECT ... FOR UPDATE statements must be routed to the PRIMARY/LEADER

To Reproduce
Steps to reproduce the behavior:

1. Create a shard to a database with leader and replica

2. Create sample table and insert data:

      CREATE TABLE usertable (
         userid INT,
         groupid INT,
         name VARCHAR(55)
      );
   
     INSERT INTO usertable (userid, groupid, name) VALUES ( 1, 1, 'bob'), (2, 1, 'Alex'), (3, 2, 'Alice');
   

3. Then do a query to a table:

   SELECT * FROM usertable u WHERE u.userid=3 FOR UPDATE;

4. Error in query [SELECT * FROM users u WHERE u.userid=3 FOR UPDATE] [ERROR: cannot execute SELECT FOR UPDATE in a read-only transaction]

[jgoday]

Hi @to2016, made this #765 PR to fix the issue.

Detecting locks (both shared and exclusive) in queries when QueryRouter tries to infer server to connect,
hopefully this will fix the issue.

[drdrsh]

I merged the patch @jgoday submitted. It is part of PR #782