cmd/jujud: don't enter upgrade mode unnecessarily

Don't enter "upgrade mode" (thereby restricting API logins and
delaying worker startup) if the current software version is the same
as the upgradedToVersion in the agent configuration.
all: use gopkg.in/juju/charm.v2

Since we already depend on gopkg.in, this should not
be blocked for the same reason as previously.
testing/factory: remove outdated reference to old charm package path
Merge pull request #253 from rogpeppe/012-charm-v2

all: use gopkg.in/juju/charm.v2

We use the new name for the charm package, and update
all places to use the new API.
Fix test for factory methods.

Service name derived from charm name if not provided.
Merge pull request #464 from tasdomas/factory-test-fix

Fix tests for factory methods.

Due to the way the factory tests were being set up, they were not being run properly. This pull request fixes that.

The problem was being caused by the factory being constructed during test setup. Since the gocheck.C object from the test setup method was being passed on to the factory, failed assertions in factory methods were not being properly handled. A gist that demonstrates this can be found here: https://gist.github.com/tasdomas/649ecf86ba43e4cd4b36

This resulted in some code being broken, but not immediately obviously so. Because of that some changes in this PR are there to make the now functional factory tests pass.
make the linux build import npipe and update dependencies.tsv to re-include npipe.  Now godeps ./... > dependencies.tsv will do the right thing.
Merge pull request #494 from natefinch/fix-npipe

Fix dependencies.tsv and make npipe always a dependency.

All builds now include a dependency on gopkg.in/natefinch/npipe.v2, so godeps ./... > dependencies.tsv will do the right thing.  This required a slight change to the npipe package so it has a file that compiles on non-windows platforms (I just moved the package docs to doc.go).
Removed invalid peergrouper test

An old test that checks that the peergrouper doesn't start with the
local provider was still present even though the peergrouper is now
always run. The reason this test has been passing is because the
peergrouper doesn't start until upgrades are finished (the test was
passing for the wrong reason). Now that upgrade mode isn't entered
unless it is necessary, this test started failing.
Merge pull request #486 from mjs/1350111-unnecessary-upgrade-mode

cmd/jujud: don't enter upgrade mode unnecessarily

Don't enter "upgrade mode" (thereby restricting API logins and delaying worker startup) if the current software version is the same as the upgradedToVersion in the agent configuration.

In addition to the automated tests included with the PR, this change has been manually tested under a variety of scenarios.
Revert "State remove setmongopassword"
Merge pull request #497 from axw/revert-414-state-remove-setmongopassword

Revert "State remove setmongopassword"
Fix LP-1355521 :: update config before making the worker
Merge pull request #500 from johnweldon/LP-1355521

Fix LP-1355521 :: update config before making the worker

Fixes lp-1355521

s.updateConfig was happening *after* the suite already set up the worker.  This resulted in the environment not being consistently initialized, and resulted in the test timing out after 10 minutes on my machine.

Moving the s.updateConfig call to the beginning of the test, like all the other tests in this file, resolved the issue.
fix panic about float in storage port, and add a test that verifies it
Merge pull request #501 from natefinch/fix-1347715

fix panic about float in storage port, and add a test that verifies it

So, this __fixes-1347715__ - at least the most problem thing to crop up.  We have tests in the code that were checking to make sure that if a float gets into the config via json deserialization, that we handle it correctly.  However, it wasn't doing precisely the same thing the production code does, so it wasn't actually getting the value into the right area of the environConfig, and wasn't actually calling storagePort().  The test I added does this, and I verified it fails with a panic with the old code for manualConfig... then fixed the code the do a type assertion first, handling float64 and int... reran the test and now the test passes.

My only concern is that I don't know what changed to cause this error to suddenly start occurring.  I'm going to look into it and see if I can find the change that revealed this error.
Cleaned up manual provider float storage port test

Avoid copying an existing test and just extend the existing one
that tests the same scenario.
Revert PR 449

PR 449 by @voidspace breaks CI, restore is using StatePort
so all restore related tests break.
Reverting until we find a solution so it does not block
CI
Merge pull request #503 from perrito666/revert_PR_449

Revert PR 449

PR 449 by @voidspace breaks CI, restore is using StatePort
so all restore related tests break.
Reverting until we find a solution so it does not block
CI
this fixes-1355324
Merge pull request #502 from mjs/float-storage-port-test

Cleaned up manual provider float storage port test

Avoid copying an existing test and just extend the existing one that tests the same scenario instead.