Change sync-tools to use API

environs/sync now operates on two interfaces:
 - a ToolsFinder, which is used for finding
   tools in the destination
 - a ToolsUploader, which is used for uploading
   missing tools to the destination

There are two implementations of ToolsFinder
and ToolsUploader: one using Storage, and one
that uses the client API.

In cmd/juju we now use the client API unless
--local-dir is specified. --public now only
takes effect if --local-dir is specified. This
is redundant anyway, given the metadata plugins.
Fix race in test.
Rework auth checks for gccgo.
simplify the change
Simplify more
Merge pull request #633 from howbazaar/fix-gccgo-failure

Rework auth checks for gccgo.

gccgo has problems comparing concrete types and interfaces. I'm betting it is actually only interfaces implemented by non-pointer types, but hey, I'm not a compiler writer.\

Reworks the auth checks.
Add doc comments for sync-tools changes
Merge pull request #625 from axw/synctools-api

Change sync-tools to use API

environs/sync now operates on two interfaces:
 - a ToolsFinder, which is used for finding
   tools in the destination
 - a ToolsUploader, which is used for uploading
   missing tools to the destination

There are two implementations of ToolsFinder
and ToolsUploader: one using Storage, and one
that uses the client API.

In cmd/juju we now use the client API unless
--local-dir is specified. --public now only
takes effect if --local-dir is specified. This
is redundant anyway, given the metadata plugins.
Merge pull request #631 from howbazaar/fix-envuser-race

Fix race in test.
Add bootstrap flag to allow failed bootstraps to keep the environment
Better warning message
Better warning message
Merge pull request #634 from wallyworld/keep-env-flag

Add bootstrap flag to allow failed bootstraps to keep the environment

Fixes: https://bugs.launchpad.net/juju-core/+bug/1362923

bootstrap now has a keep-broken flag which tells it not to cleanup after a failed bootstrap
Introduce and use FindTools provisioner API

We introduce a new FindTools API in the
provisioner facade, and move the existing
client FindTools API implementation into
the apiserver/common package. The provisioner
worker is updated to use this API instead
of going directly to provider storage (via
environs/tools.FindTools).

There are a couple of bugs already that require
this to be done, but now that we're moving tools
storage behind the API server it is imperative.

Fixes https://bugs.launchpad.net/bugs/1347984
Fixes https://bugs.launchpad.net/bugs/1304151
Merge pull request #636 from axw/provisioner-tools-api

Introduce and use FindTools provisioner API

We introduce a new FindTools API in the
provisioner facade, and move the existing
client FindTools API implementation into
the apiserver/common package. The provisioner
worker is updated to use this API instead
of going directly to provider storage (via
environs/tools.FindTools).

There are a couple of bugs already that require
this to be done, but now that we're moving tools
storage behind the API server it is imperative.

Fixes https://bugs.launchpad.net/bugs/1347984
Fixes https://bugs.launchpad.net/bugs/1304151
ActionComplete / ActionFailed called after Action completion

The worker now calls ActionComplete or ActionFailed on state, depending
on the success state of the Action and any errors.

The hook is set to an error state if the Action hook is missing, or if
other errors take place during hook execution.  If the Action hook sets
a fail state, the Hook will not error, rather the Action will fail.
ActionComplete / ActionFailed called after Action completion

ActionTags are now properly initialized on worker uniter.HookContext at the
time it is created.
ActionComplete / ActionFailed called after Action completion

Final bits and pieces to complete PR 617 put in place; tests fleshed out
and passing.
ActionComplete / ActionFailed called after Action completion

Addressed davecheney's points in PR 617.