Add deployment target metadata refresh endpoint.

So there's a lot going on here. Agents can return their metadata, which
includes the metadata from their connected adapter. This involves a lot
of requests when you go from the UI all the way to the adapter, so we
want to persist it. There are two models that can be easily confused but
are distinct. RemoteAgentMetadata is an ApiModel model that holds the
values of the agent's API response, and DeploymentTargetMetadata is the
persistence in the API.
Add metadata to serialized DeploymentTarget.
Nest metadata within metadata refresh response.

This accomplishes two things: it makes room for success/error
information in our response, and makes this endpoint easier to use in
ActiveResource. It's going to be hard to 'create' a refresh but return a
metadata object. If the refresh object that is returned contains
metadata, though, that jives better with ActiveResource.
Remove HTML representation of deployment target refresh.

This doesn't serve HTML, I was getting my responsibilities mixed up
again. When I first wrote this, I thought the browser would be hitting
this directly to avoid writing a proxy to it on the UI.
Refactor Agent service class instantiation.

Any of our agent-specific BaseProtectedService subclasses have the exact
same instantiation code, coming from attributes of the DeploymentTarget.
It cleans up the mocking-style tests quite a bit and the implementations
a little to just have the DeploymentTarget handle instantiating any of
these classes for us.
Use mocking-style test for DeploymentTarget#refresh_metadata.

I have a full integration-style tests with webmock on the refresh
controller. This relied too much on a bunch of other parts of the
system.
Add an accessor for status (used in show).
[fixes #82612694]
Seriously faraday, don't verify the cert in development.
Merge pull request #248 from CenturyLinkLabs/feature/deployment-target-metadatum

Feature/deployment target metadatum
update changelog for v0.2.8
Explicitly define required fixtures in tests.

The global fixture setting causes dozens of rows to be created and then
rolled back on every test. I feel like it's clearer when you're testing
(or reading the test) about what's involved with a system when you have
to state which fixtures you need in the context it will be used. It has
a side-effect of being significantly faster.
Merge pull request #246 from CenturyLinkLabs/chore/defusing-the-fixture-bomb

Explicitly define required fixtures in tests.
Fix some tests I broke merging in explicit fixtures.

Should have rebased.
Add missing ServiceConverter spec
Merge pull request #251 from CenturyLinkLabs/bug/fix-metadata-tests-with-implicit-fixtures

Bug/fix metadata tests with implicit fixtures
allowing remote deployment given an app id or template id

Signed-off-by: Gary Paige <gary@theoryblister.com>