Develop multi ling 03 14 2019 mb4

[mgage]

This is pretty similar to #930 but assuming multibyte capabilities of mysql.

There is a switch in site.conf.dist which turns this capability on (also an entry in localOverrides.conf).
If the switch is turned off this is compatible with older versions of mysql (before 5.3). If the switch is turned on it will build OPL databases that allow all characters. It will allow all characters in new courses that are created after the switch is turned on. It will not change courses build earlier.

As far as I can tell the earlier courses will run exactly the same as before the switch to utf8mb4. If one finds mangling of some characters with accents (mojibake)
then report this on issues.

[mgage]

I've found that encoding things in base64 and then decoding them causes a known problem. I'll post more in issue #933. It causes things like knowls to fail (which means that Solutions also fails). Most likely requires changes in both perl encode/decode and javascript encode/decode

[mgage]

In docker these commits make such things as using wide characters for user names behave correctly, even with the original utf8 database (not the one set to utf8mb4). Pulling this PR to demo.webwork.rochester.edu does not fix the problem of entering user names with wide characters :-(. even though the tables are correctly created to allow this (for the chinese2 course at least) -- Not sure what to check next -- there is probably some difference in the database configuration.

[mgage]

on the docker version of the mysql database I see
mysql> SHOW VARIABLES WHERE Variable_name LIKE 'character_set_%' OR Variable_name LIKE 'collation%';
+--------------------------+--------------------+
| Variable_name | Value |
+--------------------------+--------------------+
| character_set_client | utf8mb4 |
| character_set_connection | utf8mb4 |
| character_set_database | latin1 |
| character_set_filesystem | binary |
| character_set_results | utf8mb4 |
| character_set_server | utf8mb4 |
| character_set_system | utf8 |
| collation_connection | utf8mb4_general_ci |
| collation_database | latin1_swedish_ci |
| collation_server | utf8mb4_general_ci |
+--------------------------+--------------------+
10 rows in set (0.01 sec)

on the demo .webwork version I get

mysql> SHOW VARIABLES WHERE Variable_name LIKE 'character_set_%' OR Variable_name LIKE 'collation%';
+--------------------------+-------------------+
| Variable_name | Value |
+--------------------------+-------------------+
| character_set_client | utf8 |
| character_set_connection | utf8 |
| character_set_database | utf8 |
| character_set_filesystem | binary |
| character_set_results | utf8 |
| character_set_server | latin1 |
| character_set_system | utf8 |
| collation_connection | utf8_general_ci |
| collation_database | utf8_general_ci |
| collation_server | latin1_swedish_ci |
+--------------------------+-------------------+
10 rows in set (0.00 sec)

This would account for the different behavior. Tani has suggested that I could override
the server system variables with something like SET NAMES 'utf8mb4' but I haven't been able to get
that to work yet.