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.
Refactor timeout backoff logic

When an error occurs processing a job, the worker sets the timeout based on the
backoff logic and abandons the job. The job can then later be picked back up by
an available worker when the timeout expires. Currently the backoff logic
supports exponential backoff with a default increment value of 3 hours. I
propose a fibonacci backoff with more reasonable values.

e.g.

5s
10s
15s
25s
40s
1.08m
1.75m
2.83m
4.58m
7.42m
12.00m
19.42m
31.42m
50.83m
1.37h
2.22h
3.59h
5.81h
9.40h