terraform: iterate primary files in a deterministic order

[KetchupBomb]

Summary

Module.PartialContent iterates the m.primaries map directly. Because Go randomizes map iteration order, modules with multiple primary .tf files produce a different block order on every tflint invocation, and any rule whose logic depends on block order (e.g. "last matching block wins") produces non-reproducible results across runs of the same, unchanged config.

This mirrors the exact same bug class that was previously reported and fixed for override files — see tflint-ruleset-terraform#205 for the original symptom report (7 tflint runs on identical input, 2 failed), and #2124 for the fix that introduced overrideFilenames + sort.Strings so overrides are iterated in a stable lexicographical order. That fix never touched the general primaries path, which this PR closes.

Repro

A real Terraform module with several aws_* resources spread across multiple primary .tf files and no required_providers constraint will non-deterministically report the "missing version constraint" warning against a different resource on each tflint run (GetProviderRefs in the terraform ruleset overwrites providerRefs[providerName] on every match, so which resource "wins" the blame depends on the primary-file iteration order that this PR pins down). I hit this reliably as an intermittently-flaking Bazel tflint test — same file content, no changes, PASS/FAIL split across bazel test --runs_per_test=8.

Fix

Mirror the override treatment for primaries exactly:

1. terraform/module.go: add primaryFilenames []string to Module, initialize it in NewEmptyModule.
2. terraform/parser.go (LoadConfigDir): populate primaryFilenames as each primary file is loaded, then sort.Strings it alongside overrideFilenames.
3. terraform/module.go (Module.PartialContent): iterate m.primaryFilenames and look up m.primaries[filename], matching the existing override loop.

Test

New TestPartialContent_deterministicPrimaryOrder (in terraform/module_test.go) sets up a module with four primary files (d.tf, b.tf, a.tf, c.tf), calls PartialContent 20 times, and asserts every call returns blocks in the same lexicographical filename order (a, b, c, d). Also asserts LoadConfigDir populates primaryFilenames in sorted order.

Without the fix, Go's per-range map iteration randomization over a 4-element map makes it effectively certain that at least one of the 20 iterations returns a different order.

The existing TestRebuild fixtures were updated to also populate primaryFilenames / overrideFilenames (they construct a Module directly, bypassing NewEmptyModule / LoadConfigDir).

Downstream impact

Any downstream ruleset rule that relies on GetModuleContent / PartialContent block order for anything order-sensitive is currently exposed to this same nondeterminism — this fix benefits all rulesets, not just the resource-order-sensitive terraform_required_providers case that surfaced it.

Test plan

• go test ./terraform/... passes locally, including new TestPartialContent_deterministicPrimaryOrder
• go vet ./terraform/... clean
• CI green

[KetchupBomb]

@wata727, I realize I didn't create an issue for this first. Apologies. Happy to do so if it helps you track incoming requests.

[bendrucker]

Nice one!

[KetchupBomb]

@bendrucker , my organization prefers to go through proper Github releases for obtaining our external dependencies. Do you know when a (beta) build will be available containing this fix? Thanks for your time.

[bendrucker]

We don't do betas since it's 0.x, typical feature release cadence is every 1-2 months, bug fixes sooner. @wata727 is the one cutting releases, usually within a couple of days for a non-critical bug.