Upgrade good_job to its latest version

[mereghost]

Following up on #17327 this updates GoodJob to its latest 4.x release.

[klaustopher]

Should we make the v4 check (GoodJob.v4_ready?) somehow part of our upgrade script so that we ensure all jobs have been properly processed before this gem update?

[mereghost]

@klaustopher probably. For that we might need @machisuji to have a proper discussion.

[machisuji]

@klaustopher @mereghost I'm not sure how the v4 check would work and how we can make sure all current jobs have been processed before the upgrade. Is that even necessary? Perhaps we can talk about this in person. I'll be off until next week, Tuesday, though!

[mereghost]

Perhaps we can talk about this in person. I'll be off until next week, Tuesday, though!

Let's talk then. While important, this can wait a week. I'll try to find a time for us to talk about it.

[klaustopher]

With v4 goodjob has split jobs and job executions into 2 tables, previously everything was handled in one table and that lead to weird locking situations, etc. So they split it up. With the latest 3.x versions they have already done the split but were loading jobs from both tables. The GoodJob.v4_ready? is implemented as:

    GoodJob.migrated? && # ensures all goodjob migrations are present
    GoodJob::Job.discrete_support? && # ensures the table for discrete executions exists
    GoodJob::Job.where(finished_at: nil).where(is_discrete: [nil, false]).none? # ensures there's no more jobs that are not discrete that are not finished yet

Alternatively we can also determine this via an SQL query

SELECT COUNT(*) FROM "good_jobs" WHERE finished_at IS NULL AND is_discrete IS NOT TRUE

This should return 0 for all databases. If this is true we can savely migrate to 4.x