Fix job lock lost behavior.

In prod, we were getting tons of killed child processes,
because we use the parent process's name as the worker name
for each child, so that EACH child gets the "job lock lost"
notification, and was doing `exit!(1)`, thus dying and causing
a later job lock lost for that job, causing a cascading effect.

Our fix is to only exit the child if it is running the job
that timed out.  We use a mutex to prevent race conditions
(i.e. where the child was processing a job a moment ago when
the subscriber thread checked, but no longer is).  If the
current job does not match the job lock lost message, it is
ignored, because it is probably meant for a different child process.