Vault 22912/sync config

[maxcoulombe]

Description

This PR adds a resource to manage the global config of the enterprise Secrets Sync feature.

This API is only available on the root namespace so using a provider defined on a different namespace will error during the creation. Let me know if this is something that could/should be covered by automated tests.

Since the config is global, in theory it should not be possible to define this resource twice for the same Vault cluster but I'm not sure this is something that can be prevented as code. If a user defines the resource twice, the last config to be applied will be effective.

Checklist

• Added CHANGELOG entry (only for user-facing changes) (I feel like we can use a single CHANGELOG entry on Vinay's PR)
• Acceptance tests where run against all supported Vault Versions

/usr/local/go/bin/go tool test2json -t /home/max/.cache/JetBrains/GoLand2023.2/tmp/GoLand/___TestSecretsSyncConfig_in_github_com_hashicorp_terraform_provider_vault_vault.test -test.v -test.paniconexit0 -test.run ^\QTestSecretsSyncConfig\E$
=== RUN   TestSecretsSyncConfig
    resource_secrets_sync_config_test.go:22: Vault server version "1.16.0-beta1+ent"
--- PASS: TestSecretsSyncConfig (1.07s)
PASS

[vinay-gopalan]

Thanks for working on this! Things are looking great, had a couple initial thoughts. Whenever you get the time, could we also add the documentation for this resource to close out the loop on development? Thanks again!

[vinay-gopalan]

Let's avoid setting the default here and let the Vault default value handle that case by marking this as Computed

[maxcoulombe]

The request on the Vault side is implemented as a PATCH. If we remove the default value from the TF schema, omitting a field in the resource definition keep it as is instead of reverting to Vault's default. This may be ok if we document it accordingly but most often I've seen that removing an optional field in a TF resource should update it to some default value.

For example, if the current config is:

    "data": {
        "disabled": false,
        "queue_capacity": 1234
    },

This TF resource definition resets it to 1,000,000:

resource "vault_secrets_sync_config" "cfg" {
  disabled       = false
}

If we remove the default value here, the same TF resource definition has no effect instead because Vault is called an empty queue_capacity field.

Does that make sense? Are we fine with the behavior of not updating to a default value for a missing field?

[maxcoulombe]

Whenever you get the time, could we also add the documentation for this resource to close out the loop on development?

Done!

[maxcoulombe]

@vinay-gopalan I added the doc so I'll go ahead and merge the PR so it is ready to ship with the rest of the TFVP support. Let me know if the explanation for the default value make sense. If you'd like to discuss a different approach or there are other adjustments to do on the config resource please ping me, I'll fix them in a follow-up PR!