Extensible backup storage interface

[hongchaodeng]

Currently our backup sidecar handles the backup logic and controls how to store backup files. We have opinions in how to do it based on our experience.

However, over time we have seen growing user scenarios that are different than our "how to store files":

• User who doesn't like our config format: dont write aws creds to disk and dont require secret #1221 (comment)
• User who haves their in house storage solutions (from Ebay) (Add Swift backup driver #1245)
• User who wants new cloud features: Azure (backup to Azure #1110, backend: add Azure Blob Storage (ABS) backup support #1237), GCS (pkg/backup/gcs: initial implementation of Google Cloud Storage API #1127)
• User who want to encrypt backup: Support encryption of backup #1308

It would be reasonable to have a more extensible backup storage interface, which makes backup sidecar to only handle the backup logic, but leaves "how to store files" up to the interface. For example, have another HTTP service that serves APIs for write, read, delete, list operations of snapshot data. This would also decouple config/credential management from backup logic.

[hongchaodeng]

We should close this for #1626.
Please see and follow up conversation in that thread.