[Phase 2] Complete the provider configuration setup

[fairclothjm]

Description

Complete the provider configuration setup for the auth login methods.

This PR

Phase 2

• Modifies the internal/provider/auth.go file to handle defaults and required fields since those can no longer be set on the Provider Schema
• Modifies the auth login methods to remove defaults and make use of the new setDefaultFields method
• Adds tests for the changes to default value and env var handling
• Implements the Password Policy resources to show how a resource can work with the multiplexed providers
  • Currently, there is an issue with an import cycle, so the tests will be implemented in a separate PR

Previous Phases

Phase 0

• https://github.com/hashicorp/terraform-provider-vault/pull/2059
• Adds a multiplexer that combines the current Terraform Plugin SDK v2 Provider implementation with 0 additional providers
• Enables support for both SDKv2 and TF Plugin Framework

Phase 1

• https://github.com/hashicorp/terraform-provider-vault/pull/2067
• Introduces (in internal/provider/fwprovider) a minimal provider implementation that uses the TF Plugin Framework and muxes it with the current SDK v2-based provider's server. This new skeleton provider
• Implements 0 resources and data sources
• Is required to declare a provider schema that is identical to the schema(s) declared by all other providers in the muxed provider server
• Removes Default values from the SDK v2-based provider's schema declaration as the TF Framework-based provider does not have that facility. Defaults should be handled in the provider's ConfigureFunc

Subsequent Phases

Phase 3

• Fully migrate a resource/data source to the TF Plugin Framework

[fairclothjm]

@austingebauer Thanks for the review!

clean way to define the schema attributes of the various auth login methods in a single location instead of having them duplicated for both sdkv2/fw providers

I think we could do that if we wrote a wrapper to convert to either sdkv2 or Framework but I am not convinced that it would be worth it. I do think the change frequency is pretty low. I am happy to discuss more if you like.

Also, I am working on adding tests to assert the multiplexing schemas match. terraform apply will fail if the schemas don't match but of course we want to catch it before then. :)

[austingebauer]

@fairclothjm - Thanks! I'm good with having the fields defined in both places provided the test can make developers aware of diffs. If it becomes a pain, we can write that conversion code at a later date 👍