Fix some WP unit test errors

[JanJakes]

This PR fixes two WordPress PHPUnit test failures that I've run into:

1. Fixes ReflectionException: Property WP_SQLite_DB::$allow_unsafe_unquoted_parameters does not exist in WordPress PHPUnit tests by exposing the same private property as WPDB does and synchronizing its value when they diverge.
2. Fixes DB_NAME constant not being used in the SQLite override of WPDB. The old driver was fine using only an empty string as the database name.

[adamziel]

oh boy 🙈

As a side note, I found myself not trusting $wpdb->prepare() at all in my code. It seems weird to the point where I just stitch strings myself. I'm curious if that was your experience, too. I wonder if we have an opportunity here to make it better for SQLite and, e.g., actually use prepared statements. Probably not, because $wpdb is supposed to return a string here, but it would be cool if that was possible.

[JanJakes]

@adamziel I haven't explored $wpdb->prepare() in depth yet, but I do think it's potentially problematic — not only possible performance problems (roundtrips to MySQL server for escaping), but also the fact that it will consume any input, no matter whether it's a valid query or not, which may lead to misuse. And on top of that, you have things like this, which make me even less confident about that approach.

Considering this, I think WordPress deserves better, and maybe we could apply our learnings from implementing the SQLite driver, prototype a Postgres driver, and then see what improvements we could propose upstream.

As for what we can do with the SQLite driver itself, we only control the _real_escape WPDB method. I can see that historically, it seems to call addslashes, which I think we should replace with PDO->quote(), which should have no roundtrip cost since it's just a method call with SQLite. I'll check if using that breaks any tests.

[JanJakes]

Ah, I realized the addslashes part is correct because in that place, we emulate MySQL escaping, while escaping for SQLite is done later, when translating the literals.

[adamziel]

Escaping with slashes is difficult when we don't know the encoding of the input string. Is the byte 34 a double quote? Or is it a part of a multibyte character that we didn't recognize? Maybe we could call the method bind_utf8_string() and drop support for other encodings, then it's easy. I've been playing with escaping via bin2hex($string) in php and UNHEX() in the query. It's more computations, but it may still be faster than relying on real escape.