Add a db lock system to prevent race conditions

[RasmusSkytte]

Intent

Fixes #63

Approach

This PR adds the db locking system developed for diseasystore and expands and improves it.

The original description from diseasystore:

Four functions were written to implement flock-like locking for data base tables.
add_table_lock() a function that assigns the current process id (pid) to a given table
remove_table_lock() a function that removes the current process id (pid) from a given table
is_lock_owner() a function that returns TRUE if the current process id (pid) is assigned to a given table
remove_expired_locks() a function that removes old locks.

These locks are stored in a "locks" table in a given schema (set by the schema argument in the function calls).
Each entry is also identified by a timestamp for the lock creation "lock_start", which is used to detect stale locks.

Going from there, the remove_expired_locks() was removed and instead we throw an error in is_lock_owner() if there is a stale lock on the table.
For example, if a process crashes mid update_snapshot() we may want to not release the lock and instead create a "rollback" method to fix the botched update.

Tests were added for the functions which led to a number of fixes to the functions.

Finally, a simple implementation was made to update_snapshot where it attempts to gain lock on the table before starting the update.

Known issues

This PR also contains the code being merged in

• Delete intermediate tables after use #89

Once merged, this PR will be rebased and opened.

Tests for PostgreSQL are showing as failing.
This is caused by an update to the Workflows so that previously undetected errors are now being explicitly shown.
The source of the error is being fixed in #98

Checklist

• The PR passes all local unit tests
• I have documented any new features introduced
• If the PR adds a new feature, please add an entry in NEWS.md
• A reviewer is assigned to this PR

[LasseEngboChr]

One could consider adding an easy way to get all expired locks. And as mentioned in an inline comment then adding a username may make it safer when manually removing locks.

[RasmusSkytte]

I have refactored the three locking functions into two (lock_table and unlock_table).

lock_table returns is the merger of add_table_lock and is_lock_owner.

unlock_table is the old remove_table_lock but now also takes a pid argument to remove stale locks with different pid

[LasseEngboChr]

Great simplification - I only have a couple of small suggestions