staging_completion_handler does not attempt to start an app that has failed to stage
add diego client codepath for starting apps on diego
fix test
Move restage API docs under the apps section

[#65335102]

Signed-off-by: Chris Adams <cadams@pivotallabs.com>
fix tests, handle transactional difference between postresql and mysql
Setup the DeaClient as part of the Background Job setup

[#67453014]

Signed-off-by: Michael Fraenkel <fraenkel@us.ibm.com>
Refactor authentication and authorization

We're trying to separate these two concerns as much as possible:
- Token decoding sets the token_info in the SecurityContext. Valid
  values are stored directly, invalid values are stored as the symbol
  :invalid_token, and missing values are stored as nil.
- Authentication happens completely in the check_authentication method of
  the base controller model (base.rb). Raises NotAuthenticated if the
  token is missing; raises InvalidAuthToken if there was an error
  decoding the token. This method is called before every controller
  action is dispatched.
- Authorization happens during the validate_access method of
  model_controller. The logic for authorization is maintained in the
  Allowy access classes. Controller actions are responsible for calling this
  method (or find_and_validate_access, which defers to validate_access)
  directly.
Return InsufficientScope error when the client is missing necessary
scopes

This commit changes the way that our `validate_access` helper enforces access to resources.
Access is determined in two ways:
- First, the client used to access the resource must have appropriate
  scopes. The scopes necessary to access a particular resource are
  defined in the resource's access class, in a method with form
  `<action>_with_token?`. The action passed to `validate_access` is appended
  with `_with_token?` before being passed to Allowy. For example,
  enforcment of scopes on the read action for an App resource is found
  in the `read_with_token?` method in the AppAccess class (app_access.rb)
- Second, the user must have access to actions on the resource as defined
  by the usual methods in the resource's access class. For example,
  enforcement of authorization on the read action for an App resource is
  found in the `read?` method in the AppAccess class (app_access.rb)

We also included a few minor refactoring/renames. In particular, the
upload action in the buildpack_bits_controller now uses the same name
(instead of :read_bits) to determine access.
Service instance permissions endpoint allows
cloud_controller_service_permissions.read scope in addition to
cloud_controller.read

[finishes #68037500]
Remove unnecessary check for write scope

This action is only permitted for admin users
Clarify language/setup in specs