Reduce handler size in some ActiveJob cases, and fix deserialization inconsistency

[smudge]

This should address #23.

The issue here is that some ActiveJob-enqueued jobs would include the @job ivar in their serialized handler, which is redundant with @job_data and only existed for memoization purposes. We can use Ruby's encode_with API to ensure that we only encode @job_data into the handler.

Including @job also had the side-effect of causing DeserializationErrors and permanently failing jobs in cases where there would otherwise be a retryable NameError. Whether a missing constant should result in a DeserializationError is kind of a separate question, but since ActiveJob's stance seems to be to encode the class name as a string and only .constantize it inside of the perform, I think that it's not surprising behavior to let the NameError (and subsequent retries) occur. DeserializationError is really supposed to be only for cases where we fundamentally can't even attempt the job and allow the normal pattern of exception-handling to occur.

[smudge]

/no-platform

[effron]

Changes look good to me! Only suggestion would be to add a test that explicitly makes sure we raise a NameError and not a DeserializationError in the circumstances described here #23

Dismissed because the approval didn't include a valid comment pattern

[effron]

domainLGTM

[effron]

domainLGTM!