implement sliding next_timeout

Problem: While the worker is processing a job, it polls for image_status
and as part of it, it updates the job.status and job.next_timeout based
on the following params: [job_timeout_update_increment_min,
job_timeout_max_updates]. The timeout will be increased by
job_timeout_update_increment_min up to job_timeout_max_updates number of
times. This can push the timeout out quite a bit (i.e. typically 9
hours) since the job_timeout_update_increment_min is commonly set to 3
hours. Additionally, the timeout isn't udpated until it is expired. This
seems like a risk for allowing another worker to pick up a job that is
still being processed.

It is also worth noting that the timeout can be extended by quite a bit
by the timeout backoff logic that executes in certain error conditions.
This patch does not deal with the backoff logic.

Fix: This change introduces two new options: job_timeout_extension_sec
and job_timeout_extension_threshold_sec. The former is used to increase
the timeout when the timeout is near expiration. The latter is used to
determine when it is time to increase the timeout. The worker can
increase the timeout up to job_timeout_max_updates number of times.

Purpose of Sliding Window: An initial timeout is set so that the job can
be picked up by another worker if it is not completed within the
timeout. The sliding window allows the worker to continue working and
keep the job from being picked up by another worker. The reason a single
static timeout is not used is so that if the worker fails in some way
the job will get back into the queue for processing in a more expedient
manner.

RM4877
Merge pull request #316 from CrashenX/sliding_next_timeout

implement sliding next_timeout