Add new parameter RECREATE_KEYSTONE_DB

If 'RECREATE_KEYSTONE_DB=False' database won't be recreated.
It would be useful for multinode Grenade tests for Keystone. This parameter
will help us to deploy multiple services on different machines talking to
the same DB.

Devstack recreates Keystone DB each time during Keystone service installation.
If our controller node is already deployed, Keystone DB already contains
important information about OpenStack services and their endpoints. When
the second Keystone node is being deployed, we don't want to delete
records about controllers' services endpoints.

Partially-Implements: bp rolling-upgrade-testing

Change-Id: Ia8d07b4295ca165be01e44466c95d5275f596e83
(cherry picked from commit ea3e87d4e5)

lib/keystone

@@ -498,8 +498,10 @@ function init_keystone {
         init_ldap
     fi
 
-    # (Re)create keystone database
-    recreate_database keystone
+    if [[ "$RECREATE_KEYSTONE_DB" == True ]]; then
+        # (Re)create keystone database
+        recreate_database keystone
+    fi
 
     # Initialize keystone database
     $KEYSTONE_BIN_DIR/keystone-manage --config-file $KEYSTONE_CONF db_sync

stackrc

@@ -827,6 +827,10 @@ GIT_DEPTH=${GIT_DEPTH:-0}
 # Use native SSL for servers in ``SSL_ENABLED_SERVICES``
 USE_SSL=$(trueorfalse False USE_SSL)
 
+# We may not need to recreate database in case 2 Keystone services
+# sharing the same database. It would be useful for multinode Grenade tests.
+RECREATE_KEYSTONE_DB=$(trueorfalse True RECREATE_KEYSTONE_DB)
+
 # ebtables is inherently racey. If you run it by two or more processes
 # simultaneously it will collide, badly, in the kernel and produce
 # failures or corruption of ebtables. The only way around it is for