Check the right Info object before using in apiHostAddrs
Handle bug #1199915

Juju 1.10 doesn't set the API password for agents that are running.
So we need to set them for the workers after upgrading.
This should be a no-op for 1.11+ environments, and
properly upgrade a 1.10 into a 1.11 environment.
Add tests specific to the MachineAgent.

Discover that machine agents that aren't machine-0 weren't
forcing a state connection, but trying to read the API connection
to determine if they had state jobs to perform. However, they
can't get an API connection on an upgrade from juju-1.10.
So for now, always start the state connection, so that we
can set the API password.
Handle the no-api-password differently.

Instead of always creating the state worker early, wait until
we fail to login to the API, and then force a state connection
at that point.

This gets us closer to what we want (no state connection unless
we need it). It also means once we've set the API password,
we won't have to start the state worker early.
Implement the UnitAgent call to EnsureAPIPassword.

Split the UpgradeValidationSuite into a machine suite and a unit suite.
This is because unit needs to be a GitSuite and Machine needs to be
an lxc.TestSuite.

Both agents should now properly ensure they have a working password after
upgrade.
(broken) It turns out that 1.10 sets *nothing* for APIInfo

So rather than just setting password, we need to check for any other api
information.
I'm going to double check if 1.11 sets anything for Unit agents. If it
doesn't, then I might just punt, though I think I can do something sane.
Handle the fact that APIInfo is completely missing in 1.10 unit agent.conf.

We need to copy the contents from StateInfo, and then guess what port the API is on.
This will work for everything but if someone specifies a custom port in
environments.yaml, but I don't know why they would.
Perhaps it could be done with a State lookup for the API info, I'll ask in review.
Note, though, this is mostly compatibility so getting the 99% case should be enough.
Try to write down the permutations I've encountered.

Actually make the case where StatePassword == APIPassword == ""
not actually try to set the password again.
respond to review feedback.
Deployer client-side facade, fixes to watchers, additional tests
Merge trunk
Use State.APIAddresses rather than doing our own mangling.

State just does the same mangling we were doing (only slightly worse parsing of the IP).
However, it theoretically will read from the DB some day.
Changes after review
Merge trunk
Regularize userData.
Extract a common implementation of userData.
Remove from Azure provider as well.
Convert MAAS to loggo.
Missed a spot: the ec2 provider.
Merge trunk, resolve conflicts.