Add MysqlAdapter transactions support

[joaopgmaria]

Description

This PR adds support for MySQL read-only transactions in sandbox mode.

[erikkessler1]

We should update the README to mention that it supports MySQL too:

safer_rails_console/README.md

Line 6 in f68a534

This gem makes Rails console sessions less dangerous in specified environments by warning, color-coding, and auto-sandboxing PostgreSQL connections. In the future we'd like to extend this to make other external connections read-only too (e.g. disable job queueing, non-GET HTTP requests, etc.)

Also, we should probably update these integration tests to include support for MySQL: https://github.com/salsify/safer_rails_console/blob/master/spec/integration/patches/sandbox_spec.rb

I'd imagine the easiest way to do this would be to add a separate database in the existing apps that has a mysql adapter: https://github.com/salsify/safer_rails_console/blob/master/spec/internal/rails_7_1/config/database.yml and then add a model that uses that MySQL database.

[gremerritt]

LGTM once we add some tests.

[joaopgmaria]

@gremerritt I've reverted the changes to keep backward compatibility.
@erikkessler1 Tests are in but I am still working out one that fails despite not allowing edits to the db.

Converting this to draft pending resolution

[joaopgmaria]

Should be ready to review @erikkessler1 @gremerritt

@erikkessler1 I had to go with different environments (per adapter) instead of adapter-specific models.
For some reason, the adapter constant was not defined at startup, hence no patches were applied and thus, the failing MySQL test

[erikkessler1]

A couple last thoughts, but looking good

[erikkessler1]

Should we throw an error or provide some other indication that something has escaped the sandbox if we detect there is already an open transaction?

[joaopgmaria]

I don't think so. I'm having a hard time thinking of scenarios where this would even be possible.
Not sure if this is different in Postgres but in Mysql, since this is a new session, there shouldn't be any transactions running for this session.

There could, however, be running transactions for other session that, even if we could, we wouldn't want to make read-only. For this reason, throwing an error or informing the user doesn't make much sense to me.

I may be missing some scenarios though.

[erikkessler1]

I'm not to sure either. Unfortunately, I wasn't able to glean anything from PR that originally added it for the Postgres version.