Import block expansion with for_each

[jbardin]

This PR adds support for expanding import blocks to multiple resource instances via a for_each argument. This new for_each argument can be used to map import data to multiple resource instances, and across multiple module instances. Because it does not always correspond 1-1 with resource block, and the order of the imports is not directly related to the order of the resource instances, there is no count argument and for_each can accept all collection types in the same manner as dynamic blocks.

The PR is unfortunately a bit large, but that is primarily due to some refactoring. The refactor for_each evaluation commit breaks up the evaluation of for_each for resources into more discrete steps, so that we can share some of the important error conditions and processing with the slightly different import use case. We also move all plan-able import tests into a new context_plan_import_test.go file where the new tests are being added.

Other refactoring includes the configs.Import type, which now works primarily with hcl.Expression values, because we must always defer their evaluation until the point of resource expansion. We can statically extract the ConfigResource address (via parseConfigResourceFromExpression) from the expression to determine which configuration block to associate with the import, and store that in Import.ToResource. ImportTarget now only stores the configuration, the legacy target addr from the import command, and the evaluated ID string. When more structured import data becomes available, this can store the extended cty.Value as well.

The methodology for expansion is still to "bind" the import block to the associated resource via the ToResource address when building the graph. This is similar to how the import block works now, but we need to move evaluation around a bit to ensure we have all expansion data necessary to evaluate the for_each. In essence, the import for_each is evaluated in conjunction with the resource count or for_each, but within the root module scope. We sacrifice some detailed error help messages in the process because we no longer have all the data available (and maintaining that context all the way through would add a lot more overhead), but these are only edge cases and we make up for it in some more accurate error message with exact source locations. Simply continuing the addition of diagnostics support would likely be the most beneficial overall, and is unrelated to import itself.

A simple example using the new for_each would look like:

import {
  for_each = {
    "staging" = "bucket1"
    "uat"     = "bucket2"
    "prod"    = "bucket3"
  }
  to = aws_s3_bucket.this[each.key]
  id = each.value
}

resource "aws_sw_bucket" "this" {
  ...
}

We can also expand imports across the same resource in different module instances:

locals {
  bucket_ids = [
    { 
      group = "one"
      key   = "bucket1"
      id    = "one_1"
    },
    {
      group = "one"
      key   = "bucket2"
      id    = "one_2"
    },
    {
      group = "two"
      key   = "bucket1"
      id    = "two_1"
    },
    {
      group = "one"
      key   = "bucket2"
      id    = "two_2"
    },
  ]
}

import {
  for_each = local.bucket_ids
  id = each.value.id
  to = module.group[each.value.group].aws_s3_bucket.this[each.value.key]
}

Closes #33624

[kmoe]

I considered adding "legacy" fields to ImportTarget in #33618 but decided on the HCL synth kludge instead. Glad we are removing it.

[kmoe]

LGTM!

[github-actions]

Reminder for the merging maintainer: if this is a user-visible change, please update the changelog on the appropriate release branch.

[alezanper]

I wanted to express my excitement about this upcoming feature, which is highly anticipated for a specific use case within my role. Could you kindly provide information regarding the expected release date or version for this feature?

Thank you in advance!

[jbardin]

@alezanper, the next minor release to be cut from the main development branch will be v1.7. There is no published date for release, though you can see from historical releases that they have been about every 4 months.

[github-actions]

I'm going to lock this pull request because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active contributions.
If you have found a problem that seems related to this change, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.