secrets/database: adds ability to manage alternative credential types and configuration

[austingebauer]

Overview

This PR adds the ability for the database secrets engine to manage alternative credential types and configuration. This provides the foundation for the secrets engine to start managing database credentials other than passwords (e.g., asymmetric keys, x.509 client certificates).

Initially, this will be used to enable Vault to manage RSA key pair credentials to be consumed by the Snowflake database plugin. This will enable clients to use key pair authentication using a Vault-managed credential. See hashicorp/vault-plugin-database-snowflake#15 for example usage on the plugin side.

Dynamic Role Usage:

vault write database/roles/my-dynamic-keypair-role \
	db_name=my-snowflake-database \
	creation_statements="CREATE USER {{name}} RSA_PUBLIC_KEY='{{public_key}}'
		DAYS_TO_EXPIRY = {{expiration}} DEFAULT_ROLE=myrole;
		GRANT ROLE myrole TO USER {{name}};" \
	default_ttl="1h" \
	credential_type="rsa_private_key" \
        credential_config=key_bits=2048 \ # Optional
        credential_config=format="pkcs8"  # Optional

Static Role Usage:

vault write database/static-roles/my-static-role \
    db_name=my-snowflake-database \
    rotation_statements="ALTER USER {{name}} SET RSA_PUBLIC_KEY='{{public_key}}'" # Optional
    username="static_user_keypair" \
    rotation_period="5m" \
    credential_type="rsa_private_key" \
    credential_config=key_bits=2048 \ # Optional
    credential_config=format="pkcs8"  # Optional

Testing

Basic testing has been included in this PR. Tests that integrate with Snowflake to use RSA key pair credentials are included in the Snowflake database plugin PR.

Additional tests are in progress and will be included in further commits.

[swenson]

Maybe a minor thing, but since we're only using PEM-encoded keys, those should all be valid strings, right?

I mostly worry that bytes (or []byte) above might lead someone to think we're using something like DER.

[austingebauer]

Yep, I originally used a string type here. I would be fine going back to string since we are going with PEM encoding. Will do so if others agree.

[calvn]

I don't have a strong preference either way. FWIW the standard library call pem.EncodeToMemory also returns it as []byte.

[swenson]

LGTM. Whew, big change, but I like it. A minor possible nit/suggestion. :)