feat(cloud): Adding an upload proxy node

[mariocynicys]

This PR adds an upload proxy node. A state aware node that handles the work of uploading content to a remote location on behalf of Shaka Packager. This PR adds no new dependencies.

• The base node of the upload proxy is HTTPUpload which runs as a python thread and manages an HTTPServer that Shaka Packager should send all its requests to.
• The internal HTTPServer instantiates request handlers for requests coming from Shaka Packager, these request handlers send the incoming requests to the upload location, and they might add more headers to the request.
• Subclasses of HTTPUpload are there to support different protocols -other than http/https- for cloud providers and to extend the HTTPUpload's capabilities, but they should all use an http/https API after processing the upload url.
• Manifest files are temporarily stored in the filesystem in case of multi-period concatenation.
• RequestBodyAsFileIO is a class that digests a request body incrementally without writing it to the disk. It is used by the request handlers to send the request body that lacks an EOF to the upload location.

Issues:

• The GCS upload doesn't authenticate by itself and needs a refresh token from google's oauth 2.0 playground (but the implementation is simpler this way).
• S3 upload doesn't yet work because I haven't found google's oauth 2.0 playground counterpart for AWS yet (If it exists).
• This feature crashes on Windows (the upload node crashes) because of the presence of backslashes in the url(path) sent to the upload proxy, this happens when Shaka Packager produces files of the pattern somepath\stream_xx.m3u8 which we should be able to control using the argument --playlist_name but for some reason Shaka Packager doesn't recognize it.
• The node doesn't yet handle redirects.

[joeyparrish]

My -H "Authorization=Bearer $(gcloud auth print-access-token)" hack failed after about one hour of running. I started getting HTTP 429 responses from Google Cloud, which makes me think it wasn't an issue with the token itself, but something more fundamental we will need to resolve.

Google's docs say:

If you run into any issues such as increased latency or error rates, pause your ramp-up or reduce the request rate temporarily in order to give Cloud Storage more time to scale your bucket. You should use exponential backoff to retry your requests when:

Receiving errors with 408 and 429 response codes. Receiving errors with 5xx response codes.