Fixes bug #1364939

- Added RetryableCreationError type to the instance/instance.go, which indicates that something went
wrong during instance creationg, but the cleanup was successful and instance creation can safely be
retried
- Added transientErrorInjection channel to the dummy provider, which enables tests to
patch this variable to induce errors in instance creation (see PatchTransientErrorInjectionChannel function
and StartInstance function in provider/dummy/environs.go
- Added retry once code to the provisioner (provisioner_task.go) in case the RetryableCreationError
is received
- Added tests to the provisioner
- In the lxc.go added a destroy call if a container fails to start - we need to cleanup the environment
in case of errors - and a RetryableCreationError is returned
- Added tests to the lxc (via an error injection channel)
Fixes wrt cmars' review
Fixes wrt comments from anastasiamac
Fixes wrt comments from fwereade

- removed changes in the lxc package -> those will be in the following PR
- added NewRetryableCreationError function to the instance.go
- fixed comments in the provisioner_test.go
Fixes bug #1364939

Depends on changes in https://github.com/juju/juju/pull/1026

- Added a cleanup step in lxc.go if a containers fails to start. If the lxcContainer.Destroy() call does
not return an error a RetryableCreationError is returned, which means that it is safe for the provisioner
to retry instance creation (changes in the provisioner are in PR #1026). If the Destroy call fails
a RetryableCreationError should not be returned - a container is left in an error state and user
intervention may be required to clean up the environment.
- Added an error injection channel to the mock lxc code - if a message is received on the error injection
channel the Start or Destroy function will fail. This is used to test the changes in lxc.go.
- Added tests for the code introduced to lxc.go in lxc_test.go (see TestCreateContainerFailsWithInjectedError
and TestCreateContainerWithInjectedErrorDestroyFails)
- Fixed the CreateContainerTest in container/testing/common.go (errors.Tracef masks the true type of
the error)
Fix LP 1386968

* move things around to make recordingStorage simpler
* break out the blobs file map into its own type as that is the bit we want to interrogate after the test run
* add more locks, that always seems to help

Passes several runs of stress.bash without puking, race detector is happy as well.
Fixed error handling for RetryableCreationError
Changed the error message in case we fail to destroy the container that did not start.
Changed the transient error injection channel type to error in the dummy provider, which allows us to
inject arbitrary error types and check for correct behaviour.

Added additional tests that inject various error types into the dummy provider.
Move wire format to separate package.
- Changed error injection channel type in mock-lcs
- Changed IsRetryableCreationError function in instance.go
- Changed check for error the RetryableCreationError type
- Minor fixes to instance.go and provisioner_test.go
Merge pull request #1047 from alesstimec/retryable-creation-error-lxc

Fixes bug #1364939
responding to review feedback
Merge pull request #1042 from davecheney/208-fix-lp-1386968

Fix LP 1386968

* move things around to make recordingStorage simpler
* break out the blobs file map into its own type as that is the bit we want to interrogate after the test run
* add more locks, that always seems to help

Passes several runs of stress.bash without puking, race detector is happy as well.
provider/ec2: try next AZ on InsufficientInstanceCapacity

InsufficientInstanceCapacity may be returned by RunInstances
if the AZ cannot allocate instances of the specified instance
type. We will now handle this the same as constrained zones,
by retrying the request with the next least-populated zone.

Fixes https://bugs.launchpad.net/juju-core/+bug/1389037
provider/ec2: type switch in isZoneConstrainedError
Merge pull request #1055 from axw/lp1389037-ec2-az-InsufficientInstanceCapacity

provider/ec2: try next AZ on InsufficientInstanceCapacity

InsufficientInstanceCapacity may be returned by RunInstances
if the AZ cannot allocate instances of the specified instance
type. We will now handle this the same as constrained zones,
by retrying the request with the next least-populated zone.

Fixes https://bugs.launchpad.net/juju-core/+bug/1389037
provider/ec2: try next AZ on "no default subnet" error

If the account/region has a default VPC, but one of the
AZs lacks a default subnet, then Juju may get into a
situation where it cannot provision any instances
successfully. We handle the "no default subnet" error
just as we do constrained zones, by trying the next one.

Fixes https://bugs.launchpad.net/juju-core/+bug/1388860
Merge pull request #1056 from axw/lp1388860-ec2-nodefaultsubnet

provider/ec2: try next AZ on "no default subnet" error

If the account/region has a default VPC, but one of the
AZs lacks a default subnet, then Juju may get into a
situation where it cannot provision any instances
successfully. We handle the "no default subnet" error
just as we do constrained zones, by trying the next one.

Fixes https://bugs.launchpad.net/juju-core/+bug/1388860