Support utf8mb4

[frankiejarrett]

• When DB_CHARSET is utf8 WordPress actually forces it to be utf8mb4 instead.
• Use the $wpdb->get_charset_collate() helper method used by SQL statements in core.
• Prevent WordPress database error Specified key was too long; max key length is 767 bytes

Note
The schema for the tag and address in the tags table also had to be updated to varchar(191) to support utf8mb4 which can have up to 4 bytes per character ( 191 x 4 = 767 ) and therefore would result in an error upon table creation when using InnoDB since they are both primary keys:

WordPress database error Specified key was too long; max key length is 767 bytes.

cf.
https://developer.wordpress.org/reference/classes/wpdb/determine_charset/
https://developer.wordpress.org/reference/classes/wpdb/get_charset_collate/

[danielbachhuber]

Do we need an upgrade path for existing tables, or will existing tables continue to work as expected?

[frankiejarrett]

@danielbachhuber It continues to work in my testing so far using utf8mb4 in the DSN even though the lcache tables are still utf8. But IMO a proper migration would be safest route.

I could steal the migration path from #124 and bring it in here, leaving out the removal of the lcache_tags table. Thoughts?

[danielbachhuber]

I could steal the migration path from #124 and bring it in here, leaving out the removal of the lcache_tags table. Thoughts?

I don't think it's necessary at this point. We can revisit when we take on #123 though.