Store attributes of plugins in a separate table

This blueprint describes a mechanism to store and work with plugins attributes

Nowadays the information about plugins status and their configuration for particular cluster stored in cluster attributes. And when a plugin is deleted, it's configuration still remains in attributes of the cluster and is present in the Settings tab in UI.

To avoid this issue is proposed the following solution:

1. Add in table 'cluster_plugins' two fields to store plugins information for particular cluster:
    'enabled' - plugin status.
    'attributes' - plugin attributes.

2. Create forein key from 'cluster_plugins.cluster_id' to 'cluster.id' with cascade deleting.

3. Migrate the plugins attributes from cluster attributes into 'cluster_plugins' table.

4. Remove from plugin's attributes (stored in 'cluster_plugins' table) the 'plugin_id', 'label' and 'enabled' keys. This information will be obtained from 'enabled' field and 'plugins' table.

5. If UI requests the cluster's settings - then need to add the plugins attributes into cluster's attributes and send them to a client. If UI saves the cluster's attributes - then need to split their and save cluster's and plugins attributes separately. So in this case no need changing the UI.

6. If a new cluster is created - then add records in 'cluster_plugins' table only for compatible plugins.

7. If a new plugin is added - then add records in 'cluster_plugins' table only if the plugin is compatible with clusters.

8. If we have several version of some plugin, then user can choose a preferred version from UI or disabled all of them.