Make backup/restore happen in a separate thread

[jcscottiii]

Currently as a user running cf export-data or cf import-data, the deployed app first streams the backup to s3 / restore the backup from s3 THEN starts the server on the cloud foundry app $PORT.

For very small databases, this would be very quick and the restore/backup app would start fairly quickly. However, for big databases, I anticipate that the user would see the following for a very long time.

0 of 1 instances running, 1 starting
0 of 1 instances running, 1 starting
0 of 1 instances running, 1 starting
0 of 1 instances running, 1 starting

If the database is huge, the app may fail to start before the app push timeout expires.

This issue is basically saying, put the backup/restore logic in a separate thread.

However, doing so would mean that we would need a way to indicate if the backup succeeded/failed asynchronously.

Possibilities:

• Actually use a route for the restore/backup app and just run a GET request to get the current status.
  • Implication: The user is going to use a route from their route quota. Could run out. Need to create raw http handlers since we are keeping the python code independent of python libraries right now.
• Store the status in the environment variables.
  • Implication: The user needs to be able to go get the environment variables by either changing the target to the org and space or doing a CF curl. Either case would make things complicated for cross cloud foundry deployment transfers (EW -> GovCloud)