move timout setup as early as possible
implement simple job chaining

this patch adds another middleware `ChainMiddleware`
the middleware allows rescheduling of response from previous job as a new job
for the chain to work the following statements should be true:
- response should contain `X-Zerovm-Execute: 1.0` header
- response should contain `Content-Type: application/json` header, and effectively be a json job description

you can see that the application that tries to chain something should be able to set a _response header_
which means that application MUST use `message/cgi` or `message/http` as its output channel content type
ChainMiddleware MUST be placed anywhere before ProxyQueryMiddleware in the proxy-server pipeline

example job description that can output a chained job is:

	[
            {
                'name': 'http',
                'exec': {'path': 'swift://a/c/chainer'},
                'devices': [
                    {
                        'name': 'stdout',
                        'content_type': 'message/http'
                    }
                ]
            }
	]

as you can see, stdout has no path - will be sent to user, and its content_type is `message/http`
Merge pull request #108 from pkit/job_chain

 implement simple job chaining
contrib: add Vagrant scripts for dev environment
Merge pull request #109 from larsbutler/vagrant

Vagrant scripts for dev environment
Merge pull request #110 from pkit/minor_fixes

produce better errors in RestController
improve CGI environment handling

rewrote environment handling for REST requests (currently GET only)
now environment will be based on actual request data and headers
all sensitive headers will not be exposed to user application
more standards-compliant handling of SERVER_NAME and SERVER_PORT
Merge pull request #111 from pkit/cgi

improve CGI environment handling
change CGI environment for local objects

CGI requires passing the headers from request to the environment
up until now the local Swift object metadata was exposed through regular CGI headers (like CONTENT_LENGTH or HTTP_ETAG)
to give way to better CGI support all these headers were renamed with prefix `LOCAL_`
right now the following headers are exposed that way:

LOCAL_OBJECT - if exists, there is a local object present, if not - no other LOCAL_* vars will be present
LOCAL_CONTENT_LENGTH - size of a file
LOCAL_CONTENT_TYPE- content type of that object
LOCAL_PATH_INFO - path to the object in the format of `/account/container/obj`
LOCAL_HTTP_ETAG - etag for object (md5)
LOCAL_HTTP_X_TIMESTAMP - creation timestamp
LOCAL_HTTP_CONTENT_ENCODING - content encoding, if present
LOCAL_DOCUMENT_ROOT - path to object inside the instance `/dev/device`
LOCAL_HTTP_X_OBJECT_META_* - user metadata headers for object
fix bug in handling gzipped images

quite a tricky bug with gzipped length
was unnoticed because there was also a bug in test code, duh..
did a small rewrite of iterator handling and content_length handling
to make it easier to hunt such bugs in the future
Merge pull request #112 from pkit/bug_fix

fix bug in handling gzipped images
Merge pull request #113 from pkit/cgi

change CGI environment for local objects
vagrant/bootstrap.sh: silence wget output

The way vagrant streams the output of the progress indication of wget is
super annoying. So this adds the -q flag to reduce the noise.
Merge pull request #114 from larsbutler/vagrant-silence-wget-output

vagrant/bootstrap.sh: silence wget output
vagrant: add zerocloudrc

This file contains the necessary environment variables to use swift and
zpm clients with the machine created by this vagrant script. Just
`source zerocloudrc` to use it.
added REST interface for POST

first REST interface support added, yay!
we now support POSTing stuff to arbitrary zapp archives
using `open` version or proper `X-Zerovm-Execute` header you can POST stuff into existing zapp
example:

	POST /account/container/my_zapp-0.1/my_zapp.zapp

the zapp should expect to get a POST request, which means:
- it should have { "device": "stdin" } without a "path" property, it will recieve the payload there
- it should have some other meaninful channels configured, for example { "device": "stdout" }
- it can use job-chaining to launch another sub-job
- it can use channels connected to containers to query the containers and create dynamic sub-jobs
- etc. etc.

there are still some caveats that will be probably sdressed soon, for example: the job-chained zapp cannot recieve the POST payload instead of API endpoint zapp
Merge pull request #116 from pkit/rest

added REST interface for POST
vagrant/README: add a note about zerocloudrc
vagrant/README: add note to restart devstack

Once everything is installed and configured, you need to bounce devstack
for zerocloud and everything to work. This adds instructions for the
user/developer to do that.
Merge pull request #115 from larsbutler/vagrant-zerocloudrc

vagrant: add zerocloudrc