DB Driver: id and attempt properties not accessible during job execution

Problem

When a job is being executed all it gets is the $queue instance. It would be nice if the job could also access its own id, attempt number, and possibly other metadata during execute(). The metadata is there, it is simply not reachable from within a running job.

Use Case Examples

• Logging. If we want to do logging during execution we might want to know exactly which job ID each log record belongs to.
• Conditional execution based on the attempt number. For example if we are interacting with an API service we might wish to increase certain request delays after a previously failed job execution attempt.

Workaround

A clumsy workaround for this is to attach an event handler to Queue::EVENT_BEFORE_EXEC which copies the $id and other relevant metadata from ExecEvent into the $job instance. Very inconvenient and not backwards-compatible with stock job interface, because we must ensure the job instances we use are able to receive these properties.

Ideas

1. Store current $id, $attempt, etc. in Queue. (probably bad for any kind of parallelism)
2. Add more parameters to call (eg. $event->job->execute($this, $extra);). Possible without modifying the job interface, but kind of hacky.
3. Same as above, but also modify the job interface to predict a second parameter for execute(). (breaks BC)

Start with src/Queue.php and the execution path around Queue::EVENT_BEFORE_EXEC, then trace how ExecEvent metadata reaches execute(). Define how a running job can access its id and attempt without the workaround, while checking the listed interface and backwards-compatibility concerns.