Bug#36042078 connection fail after fallback to primary

When the client connects via the rw-splitting port and sends a read-only
statement, but the destination isn't @@super_read_only, the router will
failover to the primary.

Currently, this results in

  mysql> select @@PORT;
  ERROR 2013 (HY000): Lost connection to MySQL server during query
  No connection. Trying to reconnect...
  Connection id:    0
  Current database: *** NONE ***
  Query OK, 0 rows affected (0.09 sec)

The SELECT return a result, but returns a "OK" instead.

Background
==========

In the fallback-to-primary scenarion, the router currently sends _two_
Ok packets where it should send _one_:

  /* (   +9 us) */          connect::fetch_user_attrs::done
  /* (  +57 us) */  c<-r    io::send   // Ok - wrong
  /* (   +5 us) */          connect::check_read_only::failed
  /* ( +119 us) */          connect::pooled
  /* (   +5 us) */          connect::fallback_to_write
  ...
  /* (   +6 us) */          connect::fetch_user_attrs::done
  /* (  +41 us) */  c<-r    io::send  // Ok
  /* (  +10 us) */          connect::set_server_option::done
  /* (   +8 us) */          greeting::auth::done

Change
======

- Don't send the Auth::Ok earlier, but only at the end of the connect
  no fallover to another host can happen.
- Removed the "super-read-only" check as PRIMARYs may be reported as
  "read-only" from metadata (which don't have super-read-only set).

Change-Id: I77bf4ca25cd6abf101dcd23d76781a453ea699b5

Author: weigon