3.2.0 introduced a breaking change without a 4.0.0 version bump

[displague]

The solution to #289 introduced a breaking change without a major version bump.

Can we remove the 3.2.0 version stamp? If so, how does this affect users that are already using 3.2.0?

How does this affect users with the often suggested setting: hardware_reservation_id = "next-available"

What steps should users take when migrating to 4.0.0?

The CHANGELOG should be updated to reflect any changes and

[displague]

For example, if a user that had hardware_reservation_id = "next-available" will have a stateful value, post-provision of hardware_reservation_id = {some-uuid}.

Upon updating to 3.2.0, the next plan will want to destroy those resources to reset the hardware_reservation_id to next-available.

[displague]

To address this problem as a 3.2.1 change, the diff could be ignored when going from {uuid} to next-available. Should a 4.0.0 then revert that change to the current behavior? What migration notes should we provide?

Notes on migrating from this state should be included in equinix/terraform-provider-metal#1.