Enable archival config per domain

[andrewjdawson2016]

Diff Contains The Following

• Update IDL to include fields to operate on domain archival config
• Update schema for SQL and Cassandra to keep archival config info
• Do all plumbing between IDL and database
• Introduce deployment group into cluster config
• Add persistence level unit tests
• Add workflowHandler level unit tests
• Add admin cli to operate over archival config until we are ready to generally release archival

Concepts to Understand

• Once archival is enabled a bucket name is always set and can never be changed.
• There are three states archival can be in never_enabled, disabled and enabled. Never enabled means that archival has never been turned on for that domain. Enabled means archival is currently on for that domain and disabled means archival is currently off for domain.
• There are only three allowable archival status changes never_enabled->enabled, enabled->disabled and disabled->enabled.
• When archival is turned on for the first time a bucket name is always put in the database (either a custom user provided bucket or a default cadence bucket).
• After a bucket name is stored in the database it is never unset, even when archival is disabled.
• In order to update configuration on bucket such as retention time or owner the blobstore must be accessed directly.
• There are only three valid states database can be in: {never_enabled&"", enabled&"bucket_name", disabled&"bucket_name"}.
• The default state of the database is never_enabled and empty bucket name (all domains will start with these values). A domain can be updated to enable archival. Upon first enabling archival an already existing domain gets a one time change to optionally also set a custom bucket name.

[samarabbas]

why do we need to have a separate owner information for the bucket as part of domain configuration? This is more like bucket metadata and should belong to blob store.