Fine tune read/write locks when locking tables

[melton-jason]

Addresses part of #5337
Fixes #4148

Some raw ideas:

Make this accept two args: one for read and one for writes.

specify7/specifyweb/specify/lock_tables.py

Line 9 in dfe5887

def lock_tables(*tables):

Make this return 2 sets, one for read and one for writes. Repetition isn't allowed, so if a table is in both, elevate it to a write (just remove it from read). Put all the discipline, collection, and uniqueness rule tables, and the scope_table in the read set (basically, everything we know we won't write to)

specify7/specifyweb/specify/autonumbering.py

Line 52 in dfe5887

def get_tables_to_lock(collection, obj, field_names) -> Set[str]:

From #5337 (comment)

Now when autonumbering, Specify will only issue a write lock on the table which will be updated, read-locking all other tables. This will allow other users of Specify to read from common tables (collection, discipline, etc.) while some other user is in the process of autonumbering one or more records.
Previously, these tables would be inaccessible to other users until the autonumbering process completed. This created a massive problem when using the WorkBench and relying on autonumbering: a WorkBench validation or upload could take a significant amount of time to complete, meaning Specify would not be usable for other users.

In the future, we can extend the capability further and leverage Row Locks for even more fine-tuned control for some tables.

Checklist

• Self-review the PR after opening it to make sure the changes look good
  and self-explanatory (or properly documented)
• Add automated tests
• Add relevant issue to release milestone

Testing instructions

Coming Soon