Add new HighAvailabilityFacade for new ensure-availability command
go fmt
Tweak NewClient to improve testability
cmd/jujud: rationalised version number handling in upgrade-steps worker

1. Use version.Number's in logs and status output throughout instead
of version.Binary's. The series and architecture is irrelevant to the
upgrade process and including it just adds unnecessary verbosity.

2. The check for an already completed upgrade has been moved earlier
to avoid unnecessary initialisation.

3. New upgradeWorkerContext attributes have been added to make the
from version more accessible and the target version shorter to read
and write.
cmd/jujud: refactored upgrade logic

This revision is primarily about splitting up runUpgrades into smaller
pieces. This function was getting to be too large and difficult to
follow.
Merge pull request #732 from mjs/upgrade-sync-refactoring

state server upgrade sync refactoring

Various clean ups for the recent state server upgrade synchronisation work.
Merge branch 'master' into ensure-availability-to
Merge master, resolve conflicts
Code review tweak
Fix tests
Merge pull request #737 from wallyworld/ensure-availability-to

New HighAvailability facade

We need to add placement directives to the ensure-availability command. Hence we need to modify the API. As with most client APIs, there's one big facade. This doesn't lend itself to API versioning very well. So a new HighAvailability facade is introduced. This adds to our other existing client facades like KeyManager, UserManager etc.

Most of the changes are moving existing functionality from client -> highavailability packages. The client facade retains shims to redirect calls to the new facade.

The ensure-availability command detects whether the new facade is available and uses it if possible.

The next branch will actually do something with the placement directives.
apiserver/client: Migrated SetEnvironAgentVersion test to serverSuite
apiserver/client: clearer SetEnvironAgentVersion API error if upgrade in progress

Return an easily identifiable error from SetEnvironAgentVersion API if
the call failed because an upgrade was in progress.
cmd/juju: created interface for upgrade-juju's client API

To allow mocking in tests.
cmd/juju: upgrade-juju "upgrade in progress" handling

upgrade-juju now special-cases handling the case of the
SetEnvironAgentVersion API call failing due to an upgrade appearing to
already be in progress. The user is given guidance on what they might
be able to do to fix it.

The change introduces a struct conforming to the upgradeJujuAPI
interface to allow testing of the upgrade-juju command without making
actual API calls.
apiserver: defined "upgrade in progress" error

Avoids repeating the error code string everywhere.
cmd/juju: implemented upgrade-juju --clear-previous flag

For aborting a current UpgradeInfo document in state (in the case of
previous partially complete upgrades).
cmd/jujud: added another upgrade related wrench point

For simulating a state machine failing after it has said it's ready to
upgrade.