use the mgo built in remove rather than a custom one
Improved machine agent test setup functionality

In preparation for upcoming upgrade changes:
- machines created by primeAgent now have a pinger running so that
  EnsureAvailability can be used in tests to create additional state
  servers
- separated machine configuration from creation in primeAgent to allow
  machines created through other means (e.g. EnsureAvailability) to
  still be configured for use with machine agents
apiserver/admin: Restrict user logins

Any user login will fail unless that user exists in the environment.
Update blobstore dependency to pick up new checksum behaviour
Merge branch 'master' of https://github.com/juju/juju into login-environ-user-only
Merge pull request #712 from wallyworld/update-blobstore

Update blobstore dependency to pick up new checksum behaviour

Fixes: https://bugs.launchpad.net/bugs/1364750
cmd/jujud: synchronise state server upgrades

Use state's UpgradeInfo to synchronise state server upgrades. Overview:

- after restarting into a new tools version, master state servers will
  wait up to 15 minutes for any other state servers to indicate they
  are ready for upgrade. A downgrade to the previous tools version
  will occur if this wait times out.
- secondary state servers will wait until the master has completed its
  upgrade (to allow DB schema migrations to happen first)
- as state servers complete their upgrades they report this to the
  UpgradeInfo document. The document is archived once the last state
  server completes its upgrade.
Merge pull request #702 from waigani/login-environ-user-only

apiserver/admin: Restrict user logins

Any user login will fail unless that user exists in the environment.
Add new wrench points for upgrade-steps worker
Merge pull request #709 from mjs/upgrade-sync

cmd/jujud: synchronise state server upgrades

Use state's UpgradeInfo to synchronise state server upgrades. Overview:
    
- after restarting into a new tools version, master state servers will wait up to 15 minutes for any other state servers to indicate they are ready for upgrade. A downgrade to the previous tools version will occur if this wait times out.
- secondary state servers will wait until the master has completed its upgrade (to allow DB schema migrations to happen first)
- as state servers complete their upgrades they report this to the UpgradeInfo document. The document is archived once the last state server completes its upgrade.

Note that some refactoring to the implementation and tests is planned immediately after this PR lands. I didn't include them here because I didn't want to clutter up this PR any further.
Merge pull request #711 from wallyworld/default-lts-trusty

Change hard coded series fallback for LatestLtsSeries() to trusty

Fixes:
https://bugs.launchpad.net/bugs/1315473
https://bugs.launchpad.net/bugs/1363971

The LatestLtsSeries() detection had a hard coded fallback to "precise" when the call to 'distro-info --lts' fails. The fallback is changed to "trusty".

This covers the add-machine case (whether adding a container or a new machine) where the default-series config value is not specified.
Fix tests
Merge pull request #716 from wallyworld/default-lts-trusty-trunk

Change hard coded series fallback for LatestLtsSeries() to trusty

Ported from 1.20

Fixes:
https://bugs.launchpad.net/bugs/1315473
https://bugs.launchpad.net/bugs/1363971

The LatestLtsSeries() detection had a hard coded fallback to "precise" when the call to 'distro-info --lts' fails. The fallback is changed to "trusty".

This covers the add-machine case (whether adding a container or a new machine) where the default-series config value is not specified.
Update port conflict checker to distinguish between conflicts and exact matches.
Merge pull request #667 from tasdomas/fix-existing-port-open

Update port conflict checker to distinguish between conflicts and exact matches.

This is a fix for #1359837 (https://bugs.launchpad.net/juju-core/+bug/1359837).

Opening a port that is already open should not result in an error.
added comment regarding the use of mgo.Remove to cleanup metrics
Merge pull request #681 from mattyw/delete-metric-batch-bulk

use the mgo built in remove rather than a custom one

Previously we had our own function for deleting a metric batch during the Cleanup call. All we need to do is delete metrics based on a certain selection so we can just use collection.Remove() from mgo.
apiserver: more logging in tools download GET handler
Merge pull request #718 from axw/tools-download-moar-logging

apiserver: more logging in tools download GET handler

This is to help diagnose https://bugs.launchpad.net/juju-core/+bug/1367431