Add extra_args_array Field

[HarrisonWAffel]

Relates to : rancher/rke#2908 rancher/rancher#25500
Two new fields were added to RKE, ExtraArgsArray and WindowsExtraArgsArray. These fields allow users to specify an extraArg multiple times with different values. The provider now needs to be updated to support these two new fields.

[snasovich]

@HarrisonWAffel , since it's for TF and we have a bit more time to implement TF changes, assigning 2.6.7 milestone to it. If it's not done soon, we can bump it to 2.7.0.

[Josh-Diamond]

Test Plan - Initial Draft

Scenario 1:

• Test Case: Using tf-rke-provider, spin up cluster w/ extra_args_array containing multiple extra_args (at least 2), with each extra_arg defining at least 2 values, for each service available: [kubeapi, scheduler, etcd, etc]
• Expected Result: terraform plan should accurately represent requested infrastructure; terraform apply should successfully provision cluster

Scenario 2:

• Test Case: Using tf-rke-provider, spin up cluster w/ win_extra_args_array containing multiple extra_args (at least 2), with each extra_arg defining at least 2 values, for each service available: [kubeapi, scheduler, etcd, etc]
• Expected Result: terraform plan should accurately represent requested infrastructure; terraform apply should successfully provision cluster

[hchen-tubi]

Any progress or further plan on this? We are waiting for it and it'd be nice to have this feature available in the terraform provider

[a-blender]

Discussed this issue and PR #427 with @HarrisonWAffel last week.

There's a problem with a tf plan/apply always showing changes because the extra_args_array field is a map and maps are not ordered in Go. We could not find a workable solution to maintain the ordering that a user originally sets for extra args in the TF configuration. This is not possible because with sdk v1, there is no way to persist a map order in the TF state so when the configuration is expanded, then flattened again to read the upstream infra we have no way of knowing how the array was originally ordered.

However, this issue appears to be fixed in the migration to sdk v2 due to updates in how Terraform handles the concept of state.

The PR needs to be updated but @HarrisonWAffel is out this week so pushing this issue to release v1.4.4 so v1.4.3 can be released this week.