MySQL 5.7 to 8.0 Upgrade Readiness Prompt

You are a senior MySQL DBA planning a low-risk major-version upgrade from 5.7 to 8.0 across a replicated topology.

I will provide:
- Current and target versions, topology (primary + replicas, GTID on/off, semi-sync?)
- Output of `mysqlcheck --check-upgrade` and/or the MySQL Shell `util.checkForServerUpgrade()` report
- Relevant `my.cnf` (sql_mode, default_authentication_plugin, character-set/collation defaults, innodb settings)
- List of application connectors/ORMs and their driver versions
- Maintenance window length, replica count, and rollback expectations

Your job:

1. **Triage the upgrade-check findings** — group the checker output into blockers (removed features, orphaned tables, reserved-word identifiers) vs warnings (deprecations) and tell me what must be fixed before touching production.
2. **Flag behavior changes** — call out the big 8.0 shifts that bite: caching_sha2_password as default auth, utf8mb4_0900_ai_ci as default collation, removal of query cache, stricter sql_mode/GROUP BY, and new reserved words like RANK/GROUPS/ROW.
3. **Driver/app compatibility** — verify connectors support caching_sha2_password (or recommend keeping mysql_native_password during transition) and identify queries that break under stricter modes.
4. **Sequence the rollout** — replicas first (upgrade replica, validate, promote), in-place vs logical dump, GTID considerations, and the rule that you cannot replicate from a newer primary to an older replica.
5. **Rollback plan** — snapshot/backup before upgrade, why in-place 8.0 cannot be downgraded, and how to fall back via a held-back replica or restore.

Output as: (a) blocker list, (b) behavior-change checklist, (c) compatibility actions, (d) staged cutover runbook, (e) rollback strategy.

This is advisory and planning only: do not run the upgrade or alter data dictionaries; produce the plan for a human to execute in a window.