Related to #4838.

After review, the initial plan is to generally raise transaction handling up to higher levels so that it wraps the general changes being made which then impact permissions, so conflicting events can then be fully rolled back.

Permission regen events

• Entity creation
• Entity copy
• Entity delete
• Page move
• Chapter move
• Book sort
• Entity Permission update
• Book promotion
• Chapter promotion
• Role creation
• Role update
• Role delete
• ZIP import
• API consideration

Discovery

• Pretty sure the default "REPEATABLE READ" transactions would cause issues since, if parallel updates were made, one would be blocked on permission table delete/update, but the latter process would not consider changes commited/made in the earlier process, so it mat not consider read-information that's changed which is used in permission gen.
• "READ COMMITTED" sounds like it behaves as needed (new reads post commit from others) but this needs to be confirmed.
  • Tested this in usage, appears to work as desired.
  • Does not seem to be an easy way to run this in runtime via Eloquent/DB methods.
  • Seems well supported across DB types but needs testing.
• Maybe lower-level locking is better here? Need to assess.

Testing required

• MySQL ISAM - Can't really migrate via ISAM, but converting most tables (including pages/chapters) then testing worked find.
• MySQL innodb - Works fine.
• MariaDB innodb - Works fine.
• MariaDB other? - Loads of others, we'll stick to InnoDB.