mysql: support warning counts

[demmer]

Description

Add support for warning counts to the mysql protocol implementation. (Part 2 of #4279)

Details

This includes both client and server protocol changes to propagate the warning counts into the EOF or OK packets, based on the CapabilityClientDeprecateEOF flag.

This also changes the mysql server handler interface to include a WarningCount() API which is intended to get the warning counts from the previously executed query.

As part of this change I refactored the server implementation slightly to move the command handling into the Conn class instead of the Listenener, which enables it to be used more easily in the unit tests.

Bug

Along the way I discovered a subtle bug in the client protocol handling which turns out to have no actual ramifications. But for completeness, when the CapabilityClientDeprecateEOF flag is set, then the last packet at the end of a query is actually an OK packet with the EOF type, and not an EOF packet.

It turns out though that our client was parsing the packet as an EOF regardless of the mode:

vitess/go/mysql/query.go

Lines 380 to 390 in 58ea83c

	if isEOFPacket(data) {
	// Strip the partial Fields before returning.
	if !wantfields {
	result.Fields = nil
	}
	result.RowsAffected = uint64(len(result.Rows))
	more, err := parseEOFPacket(data)
	if err != nil {
	return nil, false, err
	}
	return result, more, nil

The only reason this works is that it turns out that the status flags happen to be in the same position in either an EOF or an OK packet IF affected_rows and last_insert_id are both 0:
https://dev.mysql.com/doc/internals/en/packet-OK_Packet.html
https://dev.mysql.com/doc/internals/en/packet-EOF_Packet.html

As such, the code didn't need to distinguish between the two cases since DMLs go through a different code path, so this turned out to be a theoretical problem that couldn't actually affect anything.

Of course now that we want the warning counts, the distinction does matter so I've fixed the handling accordingly.

[sougou]

Let's see how the merge conflict gets resolved.

[sougou]

We'll probably have to think about this when resolving the merge conflict. When the change was made to ComPing, the listener was accessible, but now it's not.

[demmer]

I just rebased the branch and handled this by stashing a reference to the listener in the Conn when used for server-side connections.

I think it's a reasonably safe invariant that Conn.handleNextCommand is only called for server-side connections for which newServerConn was used to create it.

[dweitzman]

It seems possible that one of the tests for this doesn't pass with vitess/base:percona. Here's what I'm observing:

--- FAIL: TestMultiResultDeprecateEOF (0.00s)
	client_test.go:155: Negotiated ClientDeprecateEOF flag: false, want: true
--- FAIL: TestWarningsDeprecateEOF (0.00s)
	query_test.go:252: Negotiated ClientDeprecateEOF flag: false, want: true
FAIL
FAIL	vitess.io/vitess/go/mysql/endtoend	33.617s