Manifest generation should show full service configuration information

[sethboyles]

Issue

Currently, if a service for an app was configured with parameters other than name (e.g. the parameters or binding_name field), they will not be shown when generating a manifest.

Context

Let's say we push an app with a manifest like so:

---                                                                                                                                                                                                              
applications:
- name: dora
  services:
  - name: my-service
    binding_name: my-binding
    parameters:
      foo: bar    

When we curl /v3/apps/:guid/manifest, this is what we receive:

---                                                                                                                                                                                                              
applications:
- name: dora
  services:
  - my-service

This could be an issue if one were to try applying a manifest to a different space or org to duplicate an app. It also causes or exacerbates issues with manifest diffs, such as #2201, where we cannot generate a proper diff because the logic between that endpoint and the manifest diff generation are shared.

Possible Fix

Always render services in their full configuration, instead of always rendering just their name.

[moleske]

We are looking to not do this work. @tjvman and I looked at some historical context around the work with service binding name, here is what we found.

We already store the service binding name in the DB if the user provides a name, otherwise we store NULL. When a binding has no name, it uses the name of the service instance. Given those two points, it seems straightforward to add binding name to the manifest endpoint.

From https://www.pivotaltracker.com/story/show/88670902, there is this doc. The doc has some comments about why we didn't originally include params in the DB.

The problem we're running into: there are multiple ways to modify service bindings, not all of which go through CAPI. For example, a service broker that provides a dashboard interface would potentially allow users to modify their binding parameters without ever notifying CAPI, and the OSBAPI does not describe any sort of state reconciliation mechanism for this case.

Because of this, even if we were to store binding parameters in CAPI's DB, we can't guarantee that those binding parameters would match the real state of the world. Also, service brokers are not required to support the GET service bindings endpoint - see the docs here - so we can't rely on make requests to the service broker to figure out the parameters.

The services block in the manifest is insert-only, no updates or deletes. In other words, pushing an app with a services block that contains a binding name and/or parameters then changing the binding name/parameters and re-pushing does not actually modify the binding.

Instead of trying to add service binding name and parameters, we're thinking to just ignore those fields and be consistent with how we get the manifest with the existing endpoint. This way for manifest diffs, we only compare what services are bound and not the details of those services