Use pg_advisory_unlock_all after each thread's job execution; fix Lockable return values; improve test stability

[bensheldon]

When under heavy load, as seen in tests, for an indeterminate reason, job records remain advisory locked. Rather than unlocking each record individually, this unlocks all advisory locks for the thread's database session.

Other functional improvements:

• Fixes locking query functions that return void
• Fixes return values of boolean postgres functions; using exists? would always return true in Ruby even if the function (e.g. pg_advisory_unlock had a false value in the query)

Test Improvements:

• Stubs new TestJob constant rather than stubbing over existing ExampleJob because JRuby sometimes does not stub properly and it becomes confusing to debug
• Pulls up Postgres Notice messages in tests that otherwise would go to stderr, e.g. "WARNING: you don't own a lock of type ExclusiveLock"
• Fix Appraisal gem cache
• A lot of thread-based connection and advisory lock logging, that could be removed in the future.

[bensheldon]

I think I discovered the root cause of why this change was introduced because of there being unlocked rows being returned. This is the query being used at the time of this PR:

SELECT "good_jobs".* 
FROM "good_jobs" 
WHERE "good_jobs"."id" IN (
  WITH "rows" AS MATERIALIZED ( 
    SELECT "good_jobs"."id" 
    FROM "good_jobs" 
    WHERE "good_jobs"."finished_at" IS NULL 
    AND ("good_jobs"."scheduled_at" <= '2023-10-16 14:31:18.254122' OR "good_jobs"."scheduled_at" IS NULL) 
    ORDER BY priority DESC NULLS LAST 
  ) 
  SELECT "rows"."id" 
  FROM "rows" 
  WHERE pg_try_advisory_lock(('x' || substr(md5('good_jobs' || "rows"."id"::text), 1, 16))::bit(64)::bigint) 
  LIMIT $1 
  FOR UPDATE SKIP LOCKED --- <= The problematic addition 🚨
) ORDER BY priority DESC NULLS LAST