Support Optional Super/Root User in Instance Create

[Current Behavior]

When creating a database instance, initial databases and users can optionally be included in the request:

POST /instances

{
    "instance": {
        "name": "my_db",
        "databases": [
            {
                "character_set": "utf8",
                "collate": "utf8_general_ci",
                "name": "sampledb"
            }
        ],
        "users": [
            {
                "databases": [
                    {
                        "name": "sampledb"
                    }
                ],
                "name": "sampleuser",
                "password": "samplepassword"
            }
        ],
        ...
    }
}

An important behavior to note is that when a user is provided without a list of databases:

        "users": [
            {
                "name": "sampleuser",
                "password": "samplepassword"
            }
        ],

the user is still created, but without grants for any databases.

Summary: It's possible to create initial users and databases, but it's impossible to create superusers (i.e. the equivalent of a master user/password as seen in other DBaaS offerings).

Granted, it's possible to create/reset the root user, but it must be done as a separate request, after the instance has initialized.

[Options]

Implementations Considered:

#1) Add something resembling 'CONF.default_superuser_password' to trove-guestagent.conf. If the value is non-null/empty, the 'root' user is created during the prepare phase with the password in the CONF. Add validation to the API that a user cannot be provided without a list of databases to be granted access to.

#2) Add something resembling 'CONF.root_on_create' to trove.conf. If the value is True, the 'root' user is created during the prepare phase with a UUID as the password. Said UUID is returned in the instance-create response as the 'password' property/field.

#3) Re-purpose the empty-database-list use-case above as follows: If a user is provided without a list of databases, it is assumed that the user should be classified as a superuser and granted the privileges defined by CONF.root_grant_options/CONF.root_grant.

#4) Re-purpose the empty-database-list use-case above as follows: If the 'root' user is provided without a list of databases, it is assumed that the 'root' user should be enabled with the provided password, and granted the privileges defined by CONF.root_grant_options/CONF.root_grant. If a list of databases is included with the 'root' user, the request should fail due to nonsensical intentions. Creating a superuser other than 'root' will not be supported.

Option #3 Considerations:

(3-1) With Option #3, should RootHistory still be observed?
(3-2) With Option #3, should customers not only be able to create superusers in 'create instance', but in 'create user' as well?
(3-3) With Option #3, should the customer be limited to one superuser (not including root)?

[Consensus]

Option #1 has horrifying security implications (depending on the environment), and requires the provider to message/explain the default password.

Option #3 with (3-1) and (3-2) is fairly sane, but it was decided that Option #2 was the simplest and easiest to reason about. The lack of a master/super username in Option #2 will work in our favor when multiple service types are supported, considering that some offerings don't have a root username (Redis), and others have a different root username (Cassandra).