zpm: (bundle) rename var containing auth params

The var was called "deploy"; it's been renamed to "auth", which I think
is more appropriate (since it contains, "auth url", "username",
"password" etc.). It doesn't really have anything specifically to do
with "deploy".
zpm: abstract _prepare_auth function

This function encapsulates the preparation of auth args, removing some
of the "clutter" from the `deploy_project` function.

This makes it easier to (potentially) compose small functions together
for multiple uses, and it makes unit testing easier.
zpm: (deploy) prepare authentication args first

This just cleans up the order in which things happen during deployment.
Previously, it was:

1. Get connection
2. Upload .zapp file
3. Upload job .json file
4. Prepare auth args
5. Render UI (with auth args), upload UI

The goal is to group the uploads together better, so that uploads all
happen together (and could be abstracted into a separate function). The
new order is as follows:

1. Get connection
2. Prepare auth args
3. Upload .zapp file
4. Upload job .json file
5. Render UI (with auth args), upload UI

No functionality changes here; this is pure refactoring.
zpm: abstract deployment to _deploy_zapp function

All of the actual upload/put calls are now done in `_deploy_zapp`.
zpm: add ZeroCloudConnection.authenticate method

The storage url and auth token are not cached on the connection until a
command is successfully executed. If `authenticate` is called, a
pre-authentication will be done to cache this data.
zpm: do preauth in `deploy_project`

Before we use the ZeroCloudConnection to deploy files, a preauth is
called. This is meant to ensure that the connection is always in a
consistent state before the actual deployment begins.

This helps with refactoring, too. For example, while trying to
refactor/reorder a bit of code that used this connection, I found that
the preparation of one upload relied on the fact that the previous
upload succeeded and set the `url` attributes of the connection object.

Doing this explicitly up-front prevents this sort issue from happening.
tests/test_zpm: add tests for zpm._prepare_auth
zpm: factor out deploy into Deployer class

All of the main functionality for deployment has been moved to the
Deployer class.

This makes for a good container for the various deploy functions and
utilities, and also will make things easier to test.
tests/test_zpm: test all the deploy things!

This adds tests for nearly all of the core deployment functionality, and
improves test coverage a lot. Previously, there was almost no test
coverage for this entire code path.
Merge pull request #127 from larsbutler/refactor-test-deploy

Refactor and test deploy
zpm: remove Deployer class

Classes typically represent things -- they are normally named with
nouns to reflect this. The Deployer class was encapsulating a
behavior, the deployment of a zapp. This was reflected in the fact
that the class had just one public method, this was the class' sole
behavior. The state of the class was not very interesting.

The class thus behaved very much like a function. This is a very
direct translation of the class and its methods into a set of
functions.
zpm: inline single use _upload function

When adapting the tests, it was discovered that the previous mocking
was wrong. The zpm._prepare_upload function was mocked to return

  [('a', 'b'), ('c', 'd')]

even though this is an impossible return value for it -- the function
will always return tuples where the first element contains a '/'. This
is the slash that separates the container name from the object name.

This was not discovered earlier because zpm._uploads was mocked too in
the tests and so it ignored its arguments.
zpm: let _prepare_uploads return a generator instead of a list

Returning a list implies that we buffer the data we upload in memory.
Turning the function into a generator avoids this.
Merge pull request #136 from mgeisler/remove-deployer-class

Remove deployer class
deploy: only process .tmpl files as templates (fixes #132)

When deploying a zapp, we now only treat UI file ending in .tmpl as
Jinja2 templates. Other files are uploaded verbatim.

Testing with more than one UI file showed that we implictly depended
on the order of iteration over the set returned by _find_ui_uploads.
Sets are unordered, so the tests would fail. We now return a list
instead to get deterministic output.
Merge pull request #137 from mgeisler/jinja2-ui-templates

Only process .tmpl files as Jinja2 templates (fixes #132)
deploy: show full URL to the deployed index.html (fixes #134)

Before, we would show the user that we had deployed into

  server/v1/account/container/path/

This relied on the staticweb middleware being installed and a suitable
web index being configured. We now show

  server/v1/account/container/path/index.html

instead when an index.html file is being deployed. If no index.html
file is uploaded (zapps with a non-standard UI), we show the same URL
as before and the users will have to sort things out by themselves.
deploy: always show where the zapp is deployed

The primary action of this command is to deploy a zapp. This means
that the output telling the user where to find the zapp shouldn't be
seen as info-level log output.