fix run_tests.sh deprecated warnings and pep8 issues

- fixed BaseException.message deprecated warning
- added missing file qonos/openstack/common/processutils.py
to fix one of the pep8 import issues.
- fixed import error while running hacking.py and pep8
Change default log level for iso8601

- currently the iso8601 write quite an amount of log messages on
debug mode which are not useful. To prevent the unwanted log messages
during debug mode change the log level for iso8601 to WARN
fork child process for processing job.

This patch is to enable forking of child process for processing the
given job. The forking of child process can be enabled or disabled using
the qonos worker config param flag, 'fork_child_process'. By default
fork_child_process is disabled ie., set to 'False'.

RM6152
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
Merge pull request #307 from sandeep-bhardwaj/fix_run_tests_sh_warnings

fix run_tests.sh deprecated warnings and pep8 issues
Merge pull request #308 from sandeep-bhardwaj/fix_iso8601_log_level

Change default log level for iso8601
Merge pull request #317 from CrashenX/qonos_worker_fork_proc

fork child process for processing job.
added missing import for qonos exceptions

The import for qonos exceptions was removed in a previous PR and causes
the tests to fail. This PR adds that import line back in.
Merge pull request #320 from CrashenX/missing_exception_import_in_tests

added missing import for qonos exceptions
Fix localization error in exception.py

Fix issue:-
qonos/common/exception.py:31:48: H701  Empty localization string

Also, localizes strings for other exceptions as well.
Merge pull request #319 from komawar/fix-localization-in-exception

Fix localization error in exception.py
introduce new job states, HARD_TIMED_OUT and MAX_RETRIED.

HARD_TIMED_OUT changes:

Currently, when a job hard times out, we do not update the status to
denote that the job has failed and hence there is no way to send a
job.failed notification for hard timed out jobs.
With this patch we introduce a new job state (HARD_TIMED_OUT) and based
on this new job state a job.failed notification is sent for the hard
timed out jobs.

Implementation Details:
- introduce a new job state - HARD_TIMED_OUT
- remove the filter for ignoring the hard_timed_out jobs from db
  call, _job_get_next_by_action
- instead update query criteria to ignore jobs whose status is already
  set to 'HARD_TIMED_OUT'
- implement calls for updating and sending job.failed notification in
  JobProcessor
- include tests for the changes done.

MAX_RETRIED changes:

Currently, when a job's retry_count reaches/exceeds max_retry count, we
do not update the job status to denote that the job has failed. As a
result there is no way to send job.failed notification.

This patch addresses the issue by introducing a new job status,
'MAX_RETRIED' which will get updated whenever a job's retry_count
reaches/exceeds max_retry.
Some of the key changes done as part of the patch are as follows:
- moved the config param 'max_retry' from qonos-api.conf to
  qonos-worker.conf.
- made the job processor on qonos-worker responsible for validating the
  max_retry count and based on that update the job status
- made changes to the '_job_get_next_by_action' query to ignore jobs
  whose status are set to 'MAX_RETRIED' and also removed the criteria
that checks if the job's retry_count is lesser than max_retry
- removed the job.failed notification logic from qonos.api.jobs.
- made the job.failed notification for 'MAX_RETRIED' to be sent by
  qonos-worker.
Merge pull request #1 from komawar/qonos_job_max_retried-squash

Qonos job max retried squash