SYN-4498: Fix issues with default values

[Pajk]

Before the change?

• Default values for max_wait_time and wait_for_nav_timeout are defined and used for all types of steps
• This could lead to unexpected behavior:

A) Value gets persisted in the database. That could cause validation issues - eg. in case the API introduces stricter validation.
B) Value is not persisted because the API drops it. Terraform always reports drift in the plan because the value from API differs from the configuration.

• In case the value in the database is set to 0 user is forced to change the value to a different value than the default one. The API returns 0 but the provider replaces it with the default value and reports empty plan. This happened because of a bug in v2.0.9 of this provider.

After the change?

• There are no default values for max_wait_time and wait_for_nav_timeout in the provider
• The default value is not being tracked in the TF state - it's ignored
• (not ideal) Users can't set these fields to their default values. There's a validation and the user is informed they need to set it to a different value. Since these values are ignored and not persisted to the TF state the plan would always report a change when set to the default value in the resource configuration.

I tried hard to remove this limitations but the support in terraform-plugin-sdk for working with TypeSet and ListSet is probably not sufficient. I tried all kind of approaches - Optional Computed attribute, DiffSuppressFunc, CustomizeDiff... but I was never able to cover all cases.

I haven't found a way how to ignore the value in configuration when it's set to the default value. It might be possible with the PlanModifiers when using the new terraform-plugin-framework but I was not able to modify the plan in CustomizeDiff - I was not even able to access the transactions in the new value, it was always nil.

Pull request checklist

• Acceptance Tests have been updated, run (make testacc), and pasted in this PR (for bug fixes / features)
• Docs have been reviewed and added / updated if needed (for bug fixes / features)

Acceptance Test Output

Does this introduce a breaking change?

• Yes
• No

Upgrading from any version:

• If max_wait_time or wait_for_nav_timeout is used and set to a non default value, no changes are needed and there are no changes in state or in the plan.

If users upgrade from older version than v2.0.9:

• BC: If max_wait_time is set to 10000 or wait_for_nav_timeout to 50 or 2000 the validation fails and user has to remove it from the configuration.
• If max_wait_time or wait_for_nav_timeout is not used in the configuration, no user action is required and there are no changes in state or in the plan.

If upgraded from v2.0.9 or v2.0.10:

• BC: If max_wait_time is set to 10000 or wait_for_nav_timeout to 50 or 2000 the validation will fail and user has to remove it from the configuration.
• If there're 0 values in the database and the attributes are not configured in the TF resource, no change is triggered. This has to be still fixed manually - by removing the value from the database or by setting the field to some non default value in terraform config. To fix this scenario I think we can just change the API behavior and return the default value instead 0 even when the 0 is persisted in the test config.
• If max_wait_time or wait_for_nav_timeout is not used in the configuration, no user action is required but there there will be changes in the TF state (default -> 0) so the plan will not be empty.

---

I don't think this is an ideal solution and I'm open to any suggestion how to handle this situation properly.

Other option I was thinking about was to keep the default values in the state but mirror the logic from the API to the provider and set the default only to specific test types (eg. max_wait_time for assert_* types). I didn't want to add additional logic to the provider but it might be a better solution after all.

[github-actions]

CLA Assistant Lite bot: All contributors have NOT signed the COC Document

---

I have read the Code of Conduct and I hereby accept the Terms

---

_{You can retrigger this bot by commenting recheck in this Pull Request}

[Pajk]

I have read the CLA Document and I hereby sign the CLA