EZP-28950: Add support for utf8mb4 charset to i18n

[emodric]

https://jira.ez.no/browse/EZP-28950

eZ legacy does not recognize utf8mb4 charset, instead falling back to conversion to a single byte charset set by eZTextCodec, which results in the following beautiful error messages:

Query error (1064): You have an error in your SQL syntax; check the manual that
corresponds to your MySQL server version for the right syntax to use near '???????????????????????????????????????????????????????????
?????????????????????' at line 1. Query: ?????????????????????????????????????????????????????????????????
??????????????????????????????????????????????????????????????????????
[ May 23 2018 10:47:03 ] Unexpected error, the message was : Call to a member function
attribute() on null in vendor/ezsystems/legacy-bridge/bundle/LegacyMapper/Security.php on line 97

The effect of this PR is that utf8mb4 is internally recognized as utf-8, resulting in no conversion from UTF8 taking place when used for example by the database layer.

Disclaimer: I'm not claiming that this is a proper fix, especially in this obscure part of legacy, but it seems logical :)

@glye @andrerom @gggeek @alongosz Any input on your side?

[glye]

Note: This is a prerequisite for utf8mb4 to work on legacy, but doesn't stop the old utf-8 from working. Should be backported to all supported branches.

[gggeek]

+1

[glye]

For reference, before this PR, legacy doesn't know what utf8mb4 is, and assumes it is a singlebyte encoding, which obviously fails. See

ezpublish-legacy/lib/ezi18n/classes/ezcharsetinfo.php

Line 213 in 297ff7c

return 'singlebyte';

After the fix, this returns utf-8, which means that input and output is the same, and eZTextCodec does nothing to our SQL strings, which is what we want. utf-8 in PHP is fully compatible with utf8mb4 in MySQL. See

ezpublish-legacy/lib/ezdb/classes/ezmysqlidb.php

Line 271 in 297ff7c

if ( $this->InputTextCodec )

[micszo]

Verified with sanities.

[glye]

Thanks @emodric & @micszo! Merged.