Wrap Adapter enqueue methods and Batch callbacks with Rails Reloader; verify in tests that no Advisory locks remain at database connection check-in

[bensheldon]

Follow-up to #1121, #1122 and improved verification of #1113.

Notes about Rails Executors/Reloaders

These are the general details: https://guides.rubyonrails.org/threading_and_code_execution.html

• Active Job perform is automatically wrapped with a Rails Reloader: https://github.com/rails/rails/blob/5534a2286b17e361ebfdca078e411578ed493e83/activejob/lib/active_job/railtie.rb#L63-L71
• GoodJob takes an Advisory Lock before any individual Active Job job is performed, therefore GoodJob needs to wrap its calls with an Executor or Reloader.
• Nested Executors/Reloaders are fine, because the interior nested executor/reloader will be a noop.
• When the outermost/true Executor/Reloader is done, it will check-in the current database connections.
• If a Reloader is wrapped with an Executor (e.g. Rails.application.executor.wrap { Rails.application.reloader.wrap { do_stuff } }), if code reload is triggered between the Executor and the Reloader block, the Reloader seems like it checks in the current database connections.
• Rails Minitest now does seem to wrap all tests with an Executor: Call Executor#wrap around each test rails/rails#43550
• RSpec Rails (which GoodJob uses) does not wrap with an Rails Executor: RSpec leaks ActiveSupport::ExecutionContext between specs. rspec/rspec-rails#2644 (comment)
• I believe that some of GoodJob's flaky test behavior is a result of connections with Advisory Locks being checked-in to the connection pool when Executor/Reloader boundaries are crossed.

Benefits / Risks

• In a regular application—controller actions, jobs—I would expect these additional reloaders to be noops, because controller actions and jobs are already wrapped with executors/reloaders.
• In tests, this might make tests slightly more reliable, if people are experiencing the same flakes that I am in GoodJob's test suite.
• Introducing Reloaders/Executors does add additional potential for deadlocks, but given above, I largely expect them to be noops, or running inline in tests.