Allow GoodJob.preserve_job_records to take a lambda that is callable after each job executes

[bensheldon]

1. The ActiveJob::Base instance. It's a little weird cause most experience working with jobs is from within the perform method, but most of the job properties are public.
2. the exception instance, if there is one.
3. the "error_event" which is the error handling context around the exception being raised: it will either be :discarded (from an explicit discard_on), :retry_stopped (from an explicit retry whose attempts have been exhausted), or :unhandled (which means the exception did not have an error handler at all), if there is one.

This handler is only called if the job is discardable. So if the job is still retrying (generating additional executions), it won't be called.

[Tranquility]

I think it would be great to have access to additional information like the job class and maybe even the options to decide if the job record should be preserved or not.

[bensheldon]

@Tranquility that makes sense. It's a little tricky because the Active Job instance isn't easily available in this context; the serialized parameters are easy though (e.g. job class is a string).

Can you say what you mean by "the options to decide if the job record should be preserved or not"? In my mind, this lambda would become the options.

[Tranquility]

When I said options I actually meant the arguments to the job. So the the serialized parameters.

[bensheldon]

@Tranquility thanks so much for the feedback! I've updated and I'm 99% sure I'm happy with the results.

1. The ActiveJob::Base instance. It's a little weird cause most experience working with jobs is from within the perform method, but most of the job properties are public.
2. the exception instance, if there is one.
3. the "error_event" which is the error handling context around the exception being raised: it will either be :discarded (from an explicit discard_on), :retry_stopped (from an explicit retry whose attempts have been exhausted), or :unhandled (which means the exception did not have an error handler at all), if there is one.

This handler is only called if the job is discardable. So if the job is still retrying (generating additional executions), it won't be called.