Deprecate not specifying charset

[greg0ire]

Follow up of #5277

This is similar to an issue we have had on the ORM with identifier
generator strategies: we default to some value of a setting, then
something better comes out, and we get stuck with the deprecated setting
for backward compatibility reasons.

In this case, utf8 has been deprecated for years and should no longer be
used according to the official documentation:
https://dev.mysql.com/doc/refman/8.0/en/charset-unicode-utf8.html

This kind of BC-break might be handled better by things such as Symfony
Recipes because it is OK to do such BC breaks there since they only
affect new projects.

Should we also do the same for collation? I'm not sure, but there seems to be better collations than the default one.

https://dev.mysql.com/blog-archive/new-collations-in-mysql-8-0-0/

[morozov]

I don't agree with this change: a Table object represents the user's intent to have a table in the database. The charset and collation parameters are optional because they are not portable and are not required in the CREATE TABLE DDL.

The platform-aware schema comparison logic for MySQL is aware of the default table charset and collation and uses them to compare the explicit and implicit values on the columns. It doesn't do so for the table charset/collation (#4945) which also applies to other table "options" like ENGINE.

[greg0ire]

The charset and collation parameters are optional because they are not portable and are not required in the CREATE TABLE DDL.

@morozov ok, so although this is not the right way to handle the problem, you do admit there is an issue on this line, right? If the charset parameter is optional, why is there a default value here?

[morozov]

you do admit there is an issue on this line, right?

Yes, it will be addressed by #4644.

If the charset parameter is optional, why is there a default value here?

I don't know. See #4644 (comment).