use gms engine instead of mysql handler

[jennifersp]

No description provided.

[Hydrocharged]

Great job! A lot of work, but I definitely think it'll pay off for us!

[zachmu]

This seems like an improvement, in that it puts more of the basic wire protocol in our control, rather than relying on the underlying GMS handler that Dolt instantiates. What bothers me: we're still instantiating a GMS handler on the Dolt side, which we use here or not depending on a bunch of factors.

If we've outgrown the Handler interface and need to do our own thing for better accuracy, that's great. But this only gets us partway there. Ideally Dolt no longer installs a Handler at all, and uses ours instead (or knows nothing about it). Next best thing would be that Dolt installs a Handler but we don't use it at all. This PR is at least 2 steps removed from that ideal.

I'm fine with this directionally, but we need to move quickly to a single code path managed by this package with clearly demarcated lines of responsibility, and this doesn't get us there. This makes the interaction between the packages substantially harder to reason about. Who owns getting us a cleaner set of abstractions and separation of concerns? You, or somebody else? The last major revision to this set of interactions (me, to support prepared statements) introduced a bunch of new abstractions and changes in the GMS layer to cope with. I expected to see some of that here, or the outline for a plan, or something, and I don't. It's likely that we need to move some of the functionality in the GMS Handler to a different layer of abstraction so that it can be re-used in both places that need it.

Other than that primary concern, the fact that some of the tests are now using string values instead of numerics is concerning to me. I don't see anywhere in the testing framework code explaining why this should be the case.

I don't want to block forward progress on this work, but I do need to know there is a plan to clean up the issues above and that this isn't the final state of this interaction. Daylon's OK on the overall PR for correctness etc. is fine by me.

[github-actions]

	Main	PR
Total	42090	42090
Successful	11475	11833
Failures	30615	30257
Partial Successes1	4608	4832

	Main	PR
Successful	27.2630%	28.1136%
Failures	72.7370%	71.8864%

Regressions:

date

QUERY:          SELECT EXTRACT(EPOCH FROM DATE        '1970-01-01');
RECEIVED ERROR: row sets differ:
    Postgres:
        {"0"}
    Doltgres:
        {"0.000000"}

QUERY:          SELECT EXTRACT(EPOCH         FROM DATE '2020-08-11');
RECEIVED ERROR: row sets differ:
    Postgres:
        {"1597104000"}
    Doltgres:
        {"1597104000.000000"}

numeric

QUERY:          select trim_scale(1.120);
RECEIVED ERROR: row sets differ:
    Postgres:
        {"1.12"}
    Doltgres:
        {"1.120"}

QUERY:          select trim_scale(0.00);
RECEIVED ERROR: row sets differ:
    Postgres:
        {"0"}
    Doltgres:
        {"0.00"}

QUERY:          select trim_scale(1.1234500);
RECEIVED ERROR: row sets differ:
    Postgres:
        {"1.12345"}
    Doltgres:
        {"1.1234500"}

QUERY:          select trim_scale(110123.12475871856128000);
RECEIVED ERROR: row sets differ:
    Postgres:
        {"110123.12475871856128"}
    Doltgres:
        {"110123.12475871856128000"}

QUERY:          select trim_scale(-1123.124718561280000000);
RECEIVED ERROR: row sets differ:
    Postgres:
        {"-1123.12471856128"}
    Doltgres:
        {"-1123.124718561280000000"}

QUERY:          select trim_scale(-13.00000000000000000000);
RECEIVED ERROR: row sets differ:
    Postgres:
        {"-13"}
    Doltgres:
        {"-13.00000000000000000000"}

Footnotes

1. These are tests that we're marking as Successful, however they do not match the expected output in some way. This is due to small differences, such as different wording on the error messages, or the column names being incorrect while the data itself is correct. ↩

[zachmu]

LGTM, thanks for the changes