Don't log message fields that may contain passwords.
Added tests for scrubbing senstive fields.
Remove old "health_manager_next" code and references

Signed-off-by: Alex Suraci <asuraci@pivotallabs.com>
Add a job to create/update buildpacks

Refactored based on initial comments
Update config schema for the various options
Removed the code stink from the 'should not log passwords'.
deactivating/deleting services during catalog update now scoped to broker

- extract catalog sync into service_manager object
[finishes #68026188]
Refactored App validation policies to reduce complexity.

[finishes #68152780]

Signed-off-by: James Myers <jmyers@pivotallabs.com>
improved diego staging message
* renamed uri fields to be more descriptive
* removed unused staging message fields
* renamed admin_buildpack methods to just buildpack

Signed-off-by: David Varvel <dvarvel@pivotallabs.com>
Merge pull request #176 from fraenkel/removebuildpacks

Add a job to create/update buildpacks

Re-ran travis and verified locally
Merge pull request #150 from mheath/removepasswordlogging

Don't log message fields that may contain passwords.

Verified locally, merging
Merge pull request #179 from cloudfoundry/asap/remove_health_manager

Remove old "health_manager_next" code and references
Remove remaining references to `hm9000_noop`
updating the checksum
adding Rest Api documentation for space and app summary
moving file into the new structure
Don't ignore X-Vcap-Request-Id from the router

The code in vcap.rb did not adhere to the sinatra request header
normalization conventions so it wasn't picking up the request id
propagated from the go router.
Nginx logs X-Request-Id (now set by the gorouter)

This change is in place of https://github.com/cloudfoundry/cf-release/pull/302
by @sykesm because `nginx.conf.erb` moved from `cf-release/jobs/cloud_controller_ng/templates/nginx.conf.erb`
into `cloudfoundry/cloud_controller_ng/bosh-templates`

Signed-off-by: Kai Zhang <kaizhang@cn.ibm.com>
Prevent CC from creating orphaned clients in UAA: ServiceDashboardClients can now exist without an associated broker and can be re-used

- if creating or updating a Service Broker fails (due to UAA client creation errors or any other reason), a ServiceDashboardClient is still created in the DB for each client created in UAA.
- upon a subsequent ServiceBroker create or update, any dashboard clients existing in the db with a uaa_id present in the catalog will be associated with the broker.

[finishes #65598106]
fix whitespace to appease the rubocop
Remove trial_db templates