Nailgun part of OpenStack patching feature

Feature Lead: Aleksey Kasatkin/Igor Kalnitsky
Design Reviewer: Evgeny L
Developers: Igor Kalnitsky
QA: Tatyana Leontovich

API and DB support must be provided by Nailgun to implement OpenStack patching feature.

DB considerations:
1. Release DB objects will be used to store environments’ versioning information.
2. Release also contains metadata that can be sensitive to Nailgun version. So, we can painlessly use different OpenStack releases within one Nailgun version but it can be not as easy to use them across different Nailgun versions. At least, Nailgun version should be mentioned in Release while using this approach (by adding 'compatible_fuel_versions' field).
3. Release's versions which are upgradable with current release should be mentioned in that release (e.g. current="5.1", can_update_from=["5.0", "5.0.1"]). Version has type of string.
4. Cluster will have two links with releases: current_release (always) and pending_release (when cluster state is upgrade, downgrade, etc.)
5. There are several values to add to cluster status enum: upgrade, downgrade, rollback, upgrade_error, downgrade_error, rollback_error (see https://blueprints.launchpad.net/fuel/+spec/nailgun-unified-object-model for details). Do we really need downgrade? (TBD)
6. DB changes:
6.1. Release:
- rename 'version' to 'current_os_version';
- add 'can_update_os_versions'
- add 'compatible_fuel_versions'
- add 'repo_source'
- add 'pp_modules_source'
- add 'pp_manifests_source'
6.2. Cluster:
- rename 'release_id' to 'current_release_id'
- add 'pending_release_id'
6.3. CLUSTER_STATUSES enum:
- add 'upgrade'
- add 'rollback'

API considerations:
The following actions will be added to nailgun API:
1. Add release (POST /releases/)
2. Remove release (DELETE /releases/#id/) - Do we really need this?
3. Run the update process (PUT /clusters/#id/upgrade)
4. Add notification (POST /notifications/)
POST notification request data format:
{
    cluster_id: integer, #optional
    node_id: integer, #optional
    task_id: integer, #optional
    topic: enum {'discover', 'done', 'error', 'warning'},
    message: text
}
The following actions will be changed in nailgun API:
1. Create new environment will require setting its release which depend on OpenStack version (POST /clusters/)
2. List releases will include versions info (i.e. present in nailgun DB) (GET /releases/)

Update flow:
Update starting and checking of its progress/result will be done using a task similar to deployment task. From the astute point of view it looks very similar to deployment task. The format of data exchange with orchestrator is defined in root BP.
Checking of available updates and releases’ downloading to Nailgun DB will not be supported by Nailgun in 5.0.
Rollback to previous version in case of update failure is done via API call. Really, it will do the same as update does but with different version parameters.