Backend Storage (I): Persisting MAPS (privately)

### 1. Basics

**Is your feature request related to a problem? Please describe.**
Kepler.gl has a 'Save/Share your map' feature using Dropbox but it doesn't have a way to manage privately the maps after its creation. CARTO is already working together with Kepler in the implementation of the option for [sharing maps via URL using CARTO](https://github.com/keplergl/kepler.gl/issues/746), but there is still no way to allow the user to save the map privately.

**Describe the solution you'd like**
An integrated and private system to easily persist, load and manage maps from an external provider (to be extended in a next issue for datasets).

**Describe alternatives you've considered**
- Follow a generic approach, useful for any cloud provider.
- Implementation in CARTO, as it has several APIs to manage persistence and it could also be a valuable tool for Kepler users.

### 2. Mockups & Prototype
After getting some feedback from Kepler directly and evaluating the technical challenges internally, this is our proposal for a Kepler user that wants to privately save, manage and load back maps they have created in Kepler: https://projects.invisionapp.com/share/TPTSVDX2KF5#/screens/389126759

Find screenshots of the main mockups below:
**Saving Map:**

**Loading Map:**

**Managing Maps from CARTO:**

### 3. Technical Notes

#### 3.1. Generic approach

We propose a generic approach, in which any cloud provider with an OAuth API can include a predefined set of methods to implement the backend storage feature. And that will allow the user to persist maps (and datasets), with privacy control, and to get them back from the provider with a set of visual components in Kepler (a new section in the "Add Data to Map" modal).

The first method would be one for declaring provider's *capabilities*. We're proposing these:

a) map public sharing (public url, like dropbox provider currently does)
b) map private storing (restricted url)

We propose these main methods:
- *createVisualization*. it persists the whole map's configuration and datasets in the cloud provider, and it returns a unique id for it. The metadata associated to the visualization includes:
- name
- description
- thumbnail
- privacy
- *updateVisualization*. it allows updating a visualization, keeping its id but updating some other properties (eg. new description, change privacy, new style and datasets...).
- *getVisualizations*: all / public / private. Grabs basic info from them, without returning their contents (configuration & datasets).
- *getVisualization(id)*: it gets a specific vis.
- *deleteVisualization(id)*: it removes the map from the storage.

#### 3. 2. Internal notes about CARTO storage provider

The basic mechanism would be a set of simple HTTP remote calls underneath to use the persistence capabilities of the CARTO platform APIs (namely the SQL API). Those API requests to read & write maps would be encapsulated in a CARTO JavaScript library, so the code should be quite concise in the kepler.gl side. Internally, a set of specific tables would be created in the CARTO user database, to manage public and private maps.

After a proper integration, the user would be able to manage (list, share, delete) the maps previously created from the CARTO Dashboard.

_Note:
In our particular case, the data for the map will be stored separately, since it maps nicely to the concept of a *dataset in CARTO*. This is an implementation detail, and other providers could choose to store everything together, eg. on a single JSON file (config + data) and not provide any *dataset management* capability._. We will tackle this datasets specifics in a next phase.