[draft] Fix vault_pki_secret_backend_crl_config ignoring updates of fields to their default values

[kacper1112]

Description

• switch CRL config create/update to util.GetAPIRequestDataWithSliceOkExists so zero values (for example auto_rebuild = false) are sent to Vault
• extend the acceptance test to toggle auto_rebuild back to false to guard against regressions

Initial issue reproduction steps

1. Start a Vault 1.12+ dev server and export VAULT_ADDR/VAULT_TOKEN.

2. Apply this Terraform config with the provider built from main:

   resource "vault_mount" "pki" {
     path = "pki"
     type = "pki"
   }
   
   resource "vault_pki_secret_backend_crl_config" "test" {
     backend      = vault_mount.pki.path
     auto_rebuild = true
   }
   

3. Update the config to set auto_rebuild = false and rerun terraform apply.

4. Inspect the backend: vault read pki/config/crl.

• Expected: auto_rebuild = false
• Actual: auto_rebuild remains true, showing the provider never sent the value back to Vault. This can be further inspected by logging the data.

After the patch, step 4 reports auto_rebuild = false as expected, and the new acceptance-test step now asserts this behavior.

Checklist

• Added CHANGELOG entry (only for user-facing changes): N/A
• Acceptance tests where run against all supported Vault Versions

Output from acceptance testing:

$ make testacc TESTARGS='-run=TestAccXXX'

...

Community Note

• Please vote on this pull request by adding a 👍 reaction to the original pull request comment to help the community and maintainers prioritize this request
• Please do not leave "+1" comments, they generate extra noise for pull request followers and do not help prioritize the request

PCI review checklist

• I have documented a clear reason for, and description of, the change I am making.

• If applicable, I've documented a plan to revert these changes if they require more than reverting the pull request.

• If applicable, I've documented the impact of any changes to security controls.

  Examples of changes to security controls include using new access control methods, adding or removing logging pipelines, etc.

[hashicorp-cla-app]

All committers have signed the CLA.

[hashicorp-cla-app]

Thank you for your submission! We require that all contributors sign our Contributor License Agreement ("CLA") before we can accept the contribution. Read and sign the agreement

Learn more about why HashiCorp requires a CLA and what the CLA includes

_{Have you signed the CLA already but the status is still pending? Recheck it.}

[kacper1112]

In the process of getting a formal approval to sign the CLA.