command/init: Merge duplicated PSS logic back into existing codepath

[radeksimko]

Context

Back in July we "forked" some internal init command logic to have a safer space to experiment without impacting any user unaware of the experiment.

The experiment is not concluded yet nor even ready for early adopters yet but the code structure is mostly settled and could benefit from being merged back into the main codepath, while keeping the experimental codepaths still gated behind a CLI flag and alpha releases.

More details to enable public experimentation will be published in due course.

Review Notes

As usual in my PRs, commit log should serve as your friend - i.e. I took the time to logically separate parts of the large PRs to make it easier to review.

In the process of merging I found a few bugs and discrepancies through existing tests which started failing after the merge.

Order of Operations

Order of operations during init is changing here in that provider installation was split in two phases - installing from configuration and installing from state.

Previous order:

1. initialise backend (to access remote state)
2. install providers either declared in the configuration or in state

New order:

1. install providers declared in the configuration
2. initialise backend (to access remote state)
3. install provider declared in the state (if there are any additional ones)

End-user Impact

As mentioned in the changelog entry, this should not impact the end user aside from the output from init. The same operations still happen during init, just at different times.

We are introducing 3 new log messages which are replacing an existing one in line with the above.

Old message example

JSON

{
  "@level": "info",
  "@message": "Initializing provider plugins...",
  "@module": "terraform.ui",
  "message_code": "initializing_provider_plugin_message",
  "type": "init_output"
}

Human

Initializing provider plugins...

New message examples

JSON

{
  "@level": "info",
  "@message": "Initializing provider plugins found in the configuration...",
  "@module": "terraform.ui",
  "message_code": "initializing_provider_plugin_from_config_message",
  "type": "init_output"
}

{
  "@level": "info",
  "@message": "Initializing provider plugins found in the state...",
  "@module": "terraform.ui",
  "message_code": "initializing_provider_plugin_from_state_message",
  "type": "init_output"
}

{
  "@level": "info",
  "@message": "Reusing previous version of hashicorp/local",
  "@module": "terraform.ui",
  "message_code": "reusing_version_during_state_provider_init",
  "type": "init_output"
}

Human

Initializing provider plugins found in the configuration...

Initializing provider plugins found in the state...

- Reusing previous version of hashicorp/local

Target Release

1.15.x

Rollback Plan

• If a change needs to be reverted, we will roll out an update to the code within 7 days.

Changes to Security Controls

Are there any changes to security controls (access controls, encryption, logging) in this pull request? If so, explain.

CHANGELOG entry

• This change is user-facing and I added a changelog entry.
• This change is not user-facing.

[matejrisek]

LGTM

[SarahFrench]

I don't think there's a negative impact of removing this %s as it's a new log, but the structure of the JSONValue was based on reusing_previous_version_info above, where the provider name is a prefix to the message.