In BitsExpiration#expire_droplets!, app.droplet_guid is empty

See https://cloudfoundry.slack.com/archives/C07C04W4Q/p1546603546043100 for context on #capi:

TLDR: add these lines to the api cloud_controller.yml and restart:

packages:
  max_valid_packages_stored: 2

droplets:
  max_staged_droplets_stored: 2

Create an app, get its GUID, and in two windows run the following commands while repeatedly cf push APP:

watch "cf curl /v3/apps/$GUID/packages | jq -c '.resources[] | [.guid, .state, .created_at]'"

watch "cf curl /v3/apps/$GUID/droplets | jq -c '.resources[] | [.guid, .state, .created_at]'"

Notice that we always have 2 non-expired droplets but the expected 3 non-expired packages. This is because there's a current package that is excluded from expiring, but no current droplet.

In v2/push, prepare_to_stage(app) does app.update(droplet_guid: nil)

That might be why the expirer doesn't exclude that app from its calculations

Start with BitsExpiration#expire_droplets! and the v2/push prepare_to_stage(app) path mentioned in the report. Reproduce with the packages and droplets retention settings in cloud_controller.yml, repeatedly push an app, and inspect the package and droplet lists with the provided cf curl commands. Done means the expirer correctly handles the current package and droplet state.