implements send job_error_occurred notification

When an ERROR scenario occurs while processing a job, we generally
update the job status and its timeout using worker.client.update_job()
method. But currently there is no notifications sent for the error
occurred.
This patch includes the sending of ERROR notification along
with updating of job status as similar to other job processing
notifications.
implementation includes:
- introduce a snapshot._job_error_occurred() to update the job status
  and send appropriate notification on ERROR
- modify worker.process_job() exception handling logic to update the job
  status and send job ERROR notification
- include the error message as part of the notification payload
- add more/modify tests for testing send error notification impl.
implements qonos.job.failed notification

- qonos.job.failed notification is sent only if the following criteria
  is satisfied.
  - If the job status is updated to CANCELLED
    OR
  - If the job status is updated to ERROR (AND)
    if the number of retries exceeds the max retry count (OR) if the
     current time exceeds the  hard_timeout.
- qonos.job.failed notification includes the error message to the job
  payload if it is available while updating the job status.
- modified existing tests to test the send qonos.job.failed notification
  scenario.
Merge pull request #305 from venkateshsampath/qonos_job_failed_notification

implements qonos.job.failed notification
Merge pull request #304 from venkateshsampath/job_error_occurred_notification

implements send job_error_occurred notification
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 a new option job_timeout_window_increment
that is used to increase the timeout when the timeout is near
expiration. 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