begin "Chromosome range locks" RT#274099

for backwards compatibility during migration,
  code to test whether a particular schema supports the locking regime

(human_dev passes the test because I made that table,
 but the set of columns will change)
Test::Otter - supply get_BOSDataset

same interface as get_BOLDataset,
 but "ALL" results are unfiltered
Test::Otter - muffle warnings during get_BOLDatasets

it's a grubby solution, but the test output is easier to read
B:V:SliceLock - based on B:V:ContigLock

and B:V:DBSQL:SLA based on B:V:DBSQL:CLA

mindless s/contig/slice/g to break away from the old schema
slice_locks design

tests pass, not useful yet
Test::Otter - prevent it asking for password

doesn't address the inscrutable error message
  from get_BOLDatasets('human_test')
  caused by cookie expiry inside the firewall
slice lock - update object after store

general users would need that, so don't do it just in the testcase
slice lock - test more ->new fail
slice lock - more test, begin to unlock

updating object after store
  do it for any object, not just the test subject

test+fix the fetch_by_*
  fetch_by_seq_region_id now must return a list
  by author & region need restricting to extant locks
    because we will pile up old historic ones

downgrade the objects protest of "immutable",
  where the fields are merely selectively frozen
slice locks - unlock, freshen

unlocking is done

replace timestamp-freshen with generic field freshen
  object publishes its FIELDS list to support this

tighten scope on temp vars in test, due to s/$feba/$feba2/ bug
Test::Otter - muffle "setup_pfetch_env: hostname=..." noise
slice locks - locking working, races unproven

SliceLock
  add ->is_held_sync   [test+fix]
  ->new accepts -SLICE [test+fix]
  add POD, incomplete

SLA
  implement do_lock [needs more tests]
  add POD, incomplete

tests
  do _tidy_database in main, noisily, conditional on pass
  include do_lock in exercise_tt
  check interactions of unlock with object, and copies of object
  discover new failure mode
    unlock fails by async unlock, e.g. someone breaks a long-running lock
    note this in the workflow
  extra case for the old (store, unlock) cycle

  begin to test interaction of locks with each other - more to do
slice locks - junk rejection [test+fix]
slice locks - fixes

do_lock UPDATE must also clear other 'pre' locks

clarify method name
  SliceLock->_check_fresh had nothing to do with SliceLockAdaptor->freshen

debugging of do_lock & freshen

need a bump_activity with each COMMIT
slice locks - add otter_version field

check all fields after reload
  timestamps to be tested separately
slice locks - ensure slices are forwards!

intermittent test failure was caused by backwards slices
slice locks - timestamps [test, add bump_activity]

ensure timestamps are updated, or not, during the various operations
slice locks - fix do_lock [test+fix]

extend cycle_tt to watch overlapping lock become "free(too_late)"
  do_lock failed attempting to lock the loser

also rename test vars for consistency,
  s{lock_left}{L_lock}
  s{lock_right}{R_lock}
  s{sl_left}{L_slice}
  s{sl_right}{R_slice}
slice locks - why not a Feature [pod]
slice locks - consider transaction isolation mode

ensure we aren't using the lowest ones [test+fix]
  can't run the tests on them because of our database slave config

run all database subtests in both remaining mode
  requires that author names be unique, to remain new
  take the opportunity to partially isolate from simultaneous test run,
    but _tidy_database will still clear out everything

increase slice_lock.intent field length

SliceLockAdaptor
  more info from do_lock for "confused, active=pre" failure
  guard against weird 'active'

always COMMIT at end of test