Fix MySQL isolation level for read-modify-write ops

[azdagron]

Certain operations in SPIRE are read-modify-write, i.e., they read rows, process columns on those rows, and then update the rows as part of a single transaction. This is for sensitive operations like bundle appending/pruning.

We've relied on the REPEATABLE READ isolation level to provide us the consistency guarantees we need over these kind of operations operation, namely that which prevents concurrent transactions from updating the same target row(s). This is to prevent one transaction from undoing the action just performed by another. For example, if two servers attempt to append key material to the bundle concurrently, we don't want the append op from one to accidentally "undo" the append of the other, as they are both updating the same bundle row.

We chose REPEATABLE READ based on an assumption that PostgreSQL behavior was universal.

Unfortunately MySQL REPEATABLE READ is weaker than that of PostgreSQL. While, PostgreSQL fails concurrent transactions that try to update the same target row, MySQL does not. For MySQL, we need SERIALIZABLE, which is the same as REPEATABLE READ except that it converts SELECT to SELECT ... LOCK FOR SHARE MODE which "sets a shared lock that permits other transactions to read the examined rows but not to update or delete them", which gives us the result we need.

Fixes: #2149

[rturner3]

I think we might need to do the same thing for updating of attested nodes

[azdagron]

Good catch! I've updated the PR.

[azdagron]

Github is struggling. Commit is not reflected here yet.

[rturner3]

🚀