Create "discrete" good_job_executions table to separate Job records from Execution records and have a 1-to-1 correspondence between good_jobs records and Active Job jobs

[bensheldon]

On the path to #831, which requires having a single row per job to lock, whereas currently GoodJob overloads a single table to contain both Execution and Job records, which leads to multiple rows with the same active_job_id.

This PR provides a backwards-compatible/minor-releasable change by adding a new good_job_executions table corresponding to GoodJob::DiscreteExecutions model, along with a boolean is_discrete column on Jobs/Executions. Once the migration is run, subsequently created jobs will be discrete, and they will use the new table. Old, non-discrete jobs will continue to run with multiple executions.

discrete Job records are updated in place with the most recent attributes after retries. DiscreteExecutions/good_job_executions are used to track historical changes in job attributes (#271)

Because is_discrete is a nice boolean for adding in additional behavior, a few other minor changes:

• Discrete Jobs' id is the same as the active_job_id. This is a nice alignment with Active Job.
• Discrete Jobs' all should have a scheduled_at value. If it is not actually scheduled for the future, it should be identical to the created_at value. This should help make the fetch-and-lock query a little simpler while still being able to differentiate between jobs that are intended to run immediately or are actually scheduled.

When this gets to the v3.99 release, it will be necessary to ensure that all unfinished jobs are discrete so that v4.0 can safely remove the backwards compatible code-paths. I'm imagining some kind of "Healthcheck" to peep that out, but that's not implemented here.

• Update Dashboard to show the Job's serialized_params, which is necessary because DiscreteExecutions are not created until the job is performed, which is different currently than Executions.

[bensheldon]

Benchmarking this seems very inconsequential, despite the additional transactions and inserts:

❯ ruby scripts/benchmark_discrete_jobs.rb
To use retry middleware with Faraday v2.0+, install `faraday-retry` gem
Warming up --------------------------------------
discrete jobs and no errors
                         4.000  i/100ms
undiscrete jobs and no errors
                         4.000  i/100ms
discrete jobs and 5 errors
                         4.000  i/100ms
undiscrete jobs and 5 errors
                         4.000  i/100ms
Calculating -------------------------------------
discrete jobs and no errors
                         47.279  (± 6.3%) i/s -    236.000  in   5.007317s
undiscrete jobs and no errors
                         47.613  (± 4.2%) i/s -    240.000  in   5.052548s
discrete jobs and 5 errors
                         48.203  (±12.4%) i/s -    240.000  in   5.044026s
undiscrete jobs and 5 errors
                         45.840  (± 6.5%) i/s -    232.000  in   5.080429s

Comparison:
discrete jobs and 5 errors:       48.2 i/s
undiscrete jobs and no errors:       47.6 i/s - same-ish: difference falls within error
discrete jobs and no errors:       47.3 i/s - same-ish: difference falls within error
undiscrete jobs and 5 errors:       45.8 i/s - same-ish: difference falls within error