Add dry_run and fix s3 backend merging behaviour

[lakkeger]

Motivation

• a frequently requested feature from users to be able to generate the override file for debugging purposes
• noticed by some users that the s3 backend endpoints generation was faulty

Dry run

• set via DRY_RUN env variable
• if unset:
  • if the override file exists, tflocal throws an exception
  • if the override file not existing, tflocal creates override file and calls Terraform
• if set:
  • if the override file not existing, tflocal generates the override file and exits
  • if the override file exists, prompts user to confirm overwrite and only then generates override file

S3 backend endpoints behaviour

Old behaviour

1. if endpoints block defined, uses that even if its incomplete
2. if legacy endpoint options (endpoint,sts_endpoint...etc) are present in the original file and Terraform >v1.5 it ignores these options
3. if none of the above are present generates the right endpoints config for the used Terraform version

New behaviour

Terraform version >1.5:

1. if endpoints is present:
   1. and complete, uses that
   2. and incomplete:
      1. and legacy options are present, adds legacy options and then the missing defaults
      2. and legacy options are not present, adds the missing defaults
2. if legacy options are present:
   1. and no endpoints set, uses 1.ii.a. behaviour
   2. and endpoints are set, see behaviour at endpoints

Terraform version <=1.5:

• only the legacy options accepted, if any of them missing we set the defaults
• for new options we throw exception and exit

From the created data structure according to the Terraform version generates the right s3 backend config:

• Terraform version >1.5, endpoints block
• Terraform version <=1.5, legacy options

Changes

• add DRY_RUN env variable
• add dry run behaviour
• early check for override file
• fix s3 backend endpoints behaviour
• fix s3 backend legacy options merging
• add tests for s3 backend options
• add tests for dry run

[whummer]

Kudos for tackling this @lakkeger ! Great to see that we're addressing an often requested feature from our users 🚀

I have a few minor nitpick comments, and one more fundamental question related to comparing the file hashes in the tests..

[whummer]

Kudos for the quick turnaround and addressing all the comments @lakkeger ! 🚀

[whummer]

Nice! That's great - seems much cleaner imo (and more forward-compatible) to parse the file and explicitly check for the contents we're expecting. 👌 (as compared to the file hashing)