Elaboration on the Consideration of Dropping MySQL Support

-- Motivation --

To some extent, quality requires discipline. It is not possible to write a high-quality plugin merely by writing new features. The plugin must be well-designed and well-organized, its parts well-orchestrated and understandable.

As part of the upcoming 1.0.0 version, changes are underway to database access. I think the reasons for these changes should be sufficiently clear and self-evident. In order to move forward with LibertyBans 1.0.0, it is necessary to make sweeping changes, some of which will force new approaches to difficult problems.

-- Why not MySQL: Standards Compliance --

You may be curious why it is more difficult to support MySQL than MariaDB. Although many users consider the two databases to be quite similar, MariaDB has a more expansive feature set, and in terms of compliance to the ANSI SQL standard, MariaDB is the clear winner. MySQL, in contrast, lacks elements of standard SQL, which is a severe inhibitor to effectively writing a plugin or program that uses multiple databases.

The more databases follow the SQL standard, the more it is possible to write the same code for multiple database platforms. The more databases diverge from the SQL standard, the more code which must be run with slight variations per database, resulting in the following drawbacks:
- Significantly increased code complexity
- Greater quantity of bugs
- Greater difficulty of finding bugs
- More differences in the environment which complicate debugging and testing

The end result is a greater maintenance burden, which means more time spent fixing bugs, more time on maintenance, and less time available to add sparkling new features.

In particular, maintaining MySQL support in LibertyBans would require a significant engineering effort. This would be much more than simply writing different queries per database. LibertyBans needs sequences - i.e. the `CREATE SEQUENCE` statement - as well as "simultaneous assignment," a property of `UPDATE` statements. Both sequences and simultaneous assignment adhere to the SQL standard and both are supported by MariaDB, neither by MySQL.

Dropping MySQL support in LibertyBans 1.0.0 will improve code quality, ease maintainability, and directly expand the feature set. Further on, this will enable me to stage bolder changes, make better refinements, and deliver better overall quality to the end user.

-- Why LibertyBans 0.8.x Differs --

Standards compliance wasn't an issue in LibertyBans 0.8.x, because LibertyBans 0.8.x embraced MySQL's differences. LibertyBans was able to use multiple databases by making all of those databases "emulate" MySQL (for example: HSQLDB's MySQL compatibility mode). In other words, LibertyBans 0.8.x told your database "look like MySQL, behave like MySQL, be like MySQL, and in return, I (LibertyBans personified) will interact with you as if you were MySQL."

In LibertyBans 1.0.0, for various reasons, it is no longer possible to use this workaround of "pretending everything is MySQL." Therefore, LibertyBans must be made to work across databases, even databases which are totally unlike MySQL and cannot be made to be like MySQL (such as PostgreSQL). Moreover, using standard SQL makes the codebase more accessible to contributors, which means more features and improvements; if we are very fortunate, it means additional maintainers.