Provide clearer values/deprecation notices for cleanup_interval_jobs and cleanup_interval_seconds; setting 0 disables, -1 always

[zarqman]

Per #768, this PR adds deprecation notices for certain values of cleanup_interval_jobs and cleanup_interval_seconds.

Right now, 1, 0, and any negative value are equivalent for cleanup_interval_jobs.

Likewise, 0 and any negative value are equivalent for cleanup_interval_seconds. These values also cause behavior identical to cleanup_interval_jobs: 1 which is mildly counter-intuitive to my mind. If cleaning on every job is wanted, it should be configured using cleanup_interval_jobs, not cleanup_interval_seconds.

Long term, I'll suggest that each setting should be considered disabled for values of false (ruby only) or <= 0 (both ruby and ENVs). This supports use of -1 as used elsewhere in GoodJob, and for ENVs in particular, respects the common use of =0 to disable.
Included in this PR to get from here to there:

1. Ruby values of nil are deprecated and will suggest false.
2. Ruby values <= 0 are deprecated and will suggest 1.⁺
3. ENV values of "" are deprecated and will suggest -1.
4. ENV values of 0 are deprecated and will suggest 1.⁺
5. ENV values of <= -1 are immediately changed from behaving like 1 to instead disabling.

⁺For cleanup_interval_seconds, these will suggest changing to cleanup_interval_jobs=1.

Regarding (5), without this change, it's difficult to know what action to suggest in the deprecation notice. The only existing mechanism to disable via ENV is "" which we also want to deprecate. I highly doubt -1 is being used to intentionally enable these settings, so hoping it's tolerable to change now.

Feedback welcome if this overreaches in any area.

[bensheldon]

@zarqman thank you for putting this PR together, and also for comprehensively going through the values. I'm good with the technical approach to this PR, I wanted to ask you about the values:

I'm thinking maybe I should swap the meaning of 0 and -1 in the result. As you write:

respects the common use of =0 to disable.

I wonder if the better thing would be:

• 0 disables it, in ENV and Ruby (though we recommend Ruby use false)
• -1 becomes the equivalent to "every time"

I also agree that the "number of jobs" and "number of seconds" are slightly different, but I think they should have similar configuration results for ease of understanding.

Also, for the deprecations, I think we can be a bit more aggressive. I want to propose:

1. Ruby value of nil is deprecated and will suggest false
2. Ruby value of 0 is deprecated and will suggest false <-- new
3. Ruby values < 0 are acceptable (means unlimited).
4. ENV values of "" are deprecated and will suggest 0.
5. ENV values of 0.... I wonder if we should just change that behavior right now as the old behavior is undefined. I want to imagine that anyone using 0 right now intended to disable the value, not run it all the time (I'm not sure anyone is running it all the time).
6. ENV values of <= -1 ok.

[zarqman]

I've been preoccupied with Christmas, so thanks for helping with this! 😄

Using 0 to disable makes sense to me.

A value of -1 for cleanup_interval_seconds translating into every job instead of having a time-based meaning still feels awkward to me, but I do see the benefit of these two settings having parallel values, so I'll defer to your judgment on it.