Heat/event-persistence

Motivation
Currently when we delete a stack, we remove all information associated with it from the database. This is a very bad idea (and not what AWS do) because it means that there is no record of the stack having ever existed. In particular, it is bad with the new rollback feature, since if a stack fails it will be rolled back by default and all records of *how* it failed destroyed.

Expectation
When a stack is deleted, we should mark it as deleted in the database (with a timestamp). Deleted stacks should not show up in the stack list or be accessible by name. New stacks whose names conflict with deleted stacks should be allowed. However, access to the deleted stack and its events using the ARN or UUID or (canonical) URL should be maintained.

Plan
Not breaking the existing not null constraints on the foreign keys, the minimal set of tables that has to use soft delete is user_creds and raw_template apart from the stack and event tables.

If we want to completely migrate to soft delete for all tables, like other openstack components, we can first apply soft delete to stack, event, user_creds and raw_template for now to avoid a big change at once. And after it gets merged into the code base, we can start working on the rest tables, resource, resource_data, watch_data, and watch_rule.

Major implementation steps
deleted_at              datetime deleted                 int(11)
 * Add two some volumes to the stack, event, user_cred, and raw_template tables.
 * DB migrate script
 * Downgrade needs special treatment, as dropping the extra two columns is not enough. Those records that have been marked as soft deleted should be removed first.


 * DB access layer modifications
 * Need to take into account a show_deleted option while accessing stacks, event, user_creds and raw_template.
 * Deletion to stack, event, user_cred, and raw_template tables need to be done by marking the deleting records as deleted instead of physically removing them.


 * Nested stacks
 * Treat nested stacks the same way as to resources - delete the database record.


 * heat-manage purge_events
 * To delete soft deleted database records.