feat: Add is_primary_for_scope attribute to boundary_auth_method and boundary_auth_method_password resources

[rayennh]

This PR adds a new attribute, is_primary_for_scope, for both the boundary_auth_method and boundary_auth_method_password resources.

resource "boundary_scope" "org" {
  name                     = "organization_one"
  description              = "My first scope!"
  scope_id                 = "global"
  auto_create_admin_role   = true
  auto_create_default_role = true
}

resource "boundary_auth_method_password" "password" {
  scope_id = boundary_scope.org.id
  is_primary_for_scope = true
}

Notes
I don't know what direction will be given to boundary_auth_method compared to boundary_auth_method_password. To be safe, I’ve added the new attribute to both resources for consistency.

Acceptance tests

$ TF_ACC=1 go test -run TestAccBaseAuthMethod -v ./internal/provider
=== RUN   TestAccBaseAuthMethodPassword
--- PASS: TestAccBaseAuthMethodPassword (8.68s)
=== RUN   TestAccBaseAuthMethodPasswordIsPrimary
--- PASS: TestAccBaseAuthMethodPasswordIsPrimary (13.13s)
PASS
ok      github.com/hashicorp/terraform-provider-boundary/internal/provider      22.773s

$ TF_ACC=1 go test -run TestAccAuthMethodPassword -v ./internal/provider 
=== RUN   TestAccAuthMethodPassword
--- PASS: TestAccAuthMethodPassword (9.52s)
=== RUN   TestAccAuthMethodPasswordIsPrimary
--- PASS: TestAccAuthMethodPasswordIsPrimary (12.90s)
PASS
ok      github.com/hashicorp/terraform-provider-boundary/internal/provider      23.504s

Closes #754

[louisruch]

As @moduli pointed out there are a few differences in how this is being implemented here vs oidc and ldap is there a specific reason for this?
I would need to think through this specific else case here, but the initial thoughts I am thinking about are unsetting this here might break another update that is trying to set this for the scope.

[rayennh]

@moduli @louisruch Many thanks for the review !

The differences in my implementation were intended to address two issues I encountered when reproducing the OIDC and LDAP auth method implementations:

1. Ignored updates: When is_primary_for_scope is the only attribute changed, the update is silently ignored
2. Cannot unset primary: Once an auth method is set as primary, removing or setting is_primary_for_scope = false has no effect, the auth method remains primary

My initial implementation solved both issues, but as @louisruch correctly identified, the else block introduces a race condition: if auth method A is being unset while auth method B is being set as primary simultaneously, one of them will fail with a scope version conflict error.

Proposed solution:

1. Remove the else block to prevent the race condition. This reintroduces issue 2. (cannot unset primary), but this is the same behavior as OIDC/LDAP and is probably safer from a concurrency perspective.

2. Keep the fix for issue 1. (ignored updates when only is_primary_for_scope changes) and apply it consistently to OIDC and LDAP auth methods as well.

The workaround for users who want to unset a primary auth method would be to either :

• Set another auth method as primary (which automatically unsets the previous one)
• Manually unset via the Boundary API/CLI

We could update the attribute description to document this limitation:

Description: "When true, makes this auth method the primary auth method for the scope. To unset, either set another auth method as primary or use the Boundary API/CLI directly."

What are you thoughts on this approach ?

[louisruch]

I would want to be consistent in how we approach this for all scenarios. If we want to allow unsettling - I would need to chat with the rest of the team how we want to approach this and we would need to update oidc/ldap.

Overall I am happy with this PR, my recommendation is that we remove the else block and then merge it. We can then, if we feel it is the correct approach, open a different PR to update the behavior of all oidc/ldap/password