Run mysql specs on feature branches again

What does this MR do?

At some time in the recent past we stopped running mysql specs against feature branches, instead only running them against master and the stable branches. This increases the risk of mysql-incompatible code being merged to master - which is a risk that I feel is unacceptable. In particular, it could jeopardize any security release - we'd only find out about, say, a complex, mysql-incompatible SQL change, when all the feature branches were merged into the security release branch on package release day.

I believe that if we're supporting mysql, we should treat it as a first-class citizen, which means running the test suite before merge, and taking the cost of the extra pipeline runs on feature branches (which is a real cost, in terms of both time and cash).

We have an open issue to remove mysql support, but the timeline isn't clear: https://gitlab.com/gitlab-org/gitlab-ce/issues/52442 - if we had a defined end date for this situation that was coming in the next release or two, I'd feel more comfortable about running the risk, but we don't, so it leaves me feeling very uncomfortable. Hence this MR.

This may be a controversial change so I'm going to cc all of @gitlab-org/maintainers/rails-backend :). Also @engwan @joshlambert @kencjohnston , who have all been involved in the mysql support issue.

Related to #52442 (closed)