Support

First of all, it's normal to have a mix of collations when you try to convert a site. Some older software may have not updated its database structure for UTF8MB4 requirements. For instance, MySQL only allows database keys with entries up to 767 bytes long. If you have a VARCHAR(192) column it takes up 3 x 192 = 576 bytes under UTF8 but 4 x 192 = 768 bytes under UTF8MB4. This makes it an invalid key size. If there's an INDEX / KEY on that column the conversion to UTF8MB4 will fail, therefore it needs to remain plain old UTF8.

That said, this has absolutely nothing to do with your problem! If you look at the error message, it tells you that trying to write to the Joomla menu table failed because something tried to store the value -1 on a column which is supposed to only accept unsigned long integers. "Unsigned" means "without a sign", i.e. only positive values. Clearly, -1 is negative, not positive, hence it's out of range.

The level column where this happens is what is used internally by Joomla! to figure out the hierarchy of menu items. Therefore the error message tells us that your Joomla! menu structure is, not to put too fine a point on it, cocked up. The first thing you should try is going to the backend of your site, Menus, Manage and click the Rebuild button in the toolbar. It tries to fix exactly this kind of issues.

If that didn't make any difference then you should probably rebuild your site, as painful as it may be, because that'd mean you have a far more complicated issue.

PS: You may wonder why this happened when you tried to install an update. It's probably because Joomla is trying to regenerate the backend Components menu during the update of any component. Since the menus table, shared by the front- and backend, is screwed up this triggered an invalid data write which raised the database error.

Developers want to rewrite their code to take advantage of improvements in PHP, MySQL and Joomla! itself. The problem is that users and hosts don't want to upgrade their PHP and MySQL versions. Case in point: I am still supporting PHP 5.4, a version of PHP which stopped receiving even bug fixes on September 3rd, 2015. Its usage only dropped below the point where I can safely discontinue supporting it two months ago. If you ask me as a developer I only want to support PHP 7.2 and 7.3, MySQL 5.7 and Joomla! 3.9 at the time of this writing.

Regarding indices, it's mostly the fault of developers and bad conventions. Most of us used a VARCHAR(255) for title fields. That seemingly random number comes from the MySQL index size and the fact that MySQL would only support 3-byte UTF8 until quite recently. When we wanted to create an index we would create an index on the field without any qualifiers. This was stupid because that slows down MySQL when searching in most cases. What we should do is put a qualifier on the maximum length of the index, e.g. tell it to create an index on some_field(30) which tells MySQL "index only the first 30 characters". On most sites this only puts a dozen or two of rows into each index position. This means a much more compact index (MySQL can read it faster) for a tradeoff of processing a dozen or so rows instead of just one. When you do the math, it's faster. I did NOT know any of that because I am developer, not a database administrator. I watched a presentation a few years ago by a database admin on the subject. But can I apply it on my software? It's complicated and error-prone. I am still trying to find a good solution to a past mistake...

I am glad you managed to fix your site :) I am always of the mind that fixing should first be attempted before applying the nuclear option. I've seen too many "developers" offer the nuclear option for trivial issues which ultimately drove clients away from the CMS, making them think that if anything slightly breaks their site is hosed. I hate that mentality. I hate these "developers". Joomla is a great CMS with a lot of options to help you fix most cock-ups imagineable. All a developer has to do to help their clients is actually know how the CMS works and, most importantly, how to use the CMS.