Use nova service doubles in nova tests

This branch plugs the nova service doubles into the nova live tests and makes everything work.
So now, in the nova package, "go test -gocheck.v" runs the tests against the doubles, and
"go test -gocheck.v -live" uses an Openstack instance.

Also, the rate limit retry test is now only run locally against the service doubles, where a special
request is used to trigger a rate limit service response. This replaces the previous test which
hammered a real Openstack instance to try and induce a rate limit response.

A few things needed to be done, and as a result of implementation changes to the service doubles,
changes were also needed for the service double unit tests.

 Viewing highlights:

1. Default security group

A real Openstack instance always has a default security group. The nova double and associated unit tests were modified
accordingly.

2. Out of the box flavours

The real Openstack instance used for testing has flavours defined out of the box. The live tests assume this behaviour
so the test double needed to be modifed to match.

3. Response changes

Some changes were required to certain response data eg creating a security group rule

4. ** This issue will need a follow up change **

The security group rule response contains a SecurityGroupRef struct:

type SecurityGroupRule struct {
        FromPort      *int              `json:"from_port"`   // Can be nil
        IPProtocol    *string           `json:"ip_protocol"` // Can be nil
        ToPort        *int              `json:"to_port"`     // Can be nil
        ParentGroupId int               `json:"parent_group_id"`
        IPRange       map[string]string `json:"ip_range"` // Can be empty
        Id            int
        Group         SecurityGroupRef
}

The was defined as a pointer ie  Group *SecurityGroupRef.
However, nova double tests which do a DeepEquals to compare security group rules
fail because the pointer deferencing isn't done. So to make stuff work, I've
used a struct value instead and use the zeroSecurityGroupRef pattern as used
on the ec2 side. This isn't desirable and should be looked at. But if we are
prepared to go with it for now, it can be fixed in a followup branch. BTW, nothing
uses this attribute value so the change should not break juju core.

R=dimitern, jameinel
CC=
https://codereview.appspot.com/7098074