Add mean to denote resource restarts/downtime during plan, similar to ForceNew

[pdecat]

Following up on @bflad's suggestion in https://github.com/terraform-providers/terraform-provider-aws/pull/2250#pullrequestreview-75794601, it would be great if Terraform core supported denoting resource restarts/downtime during plan phase, similar to how it denotes recreation (forces new resource).

Maybe adding a schema modifier like ForcesDowntime like the ForcesNew would do it.

For example, adding ForcesDowntime to the instance_type field of an EC2 instance would warn the user executing the plan that his modification to the configuration, or an out of band modification, will result in downtime of that instance.

[radeksimko]

Just adding another idea for potential name of this future field as I couldn't find this issue through GitHub search: RequiresInterruption

Work on this (and the exact implementation) is however yet to be scheduled and name yet to be decided, all of which won't happen until after 0.12.

[apparentlymart]

A while back when we were prototyping different UI for diffs we included the idea of service interruptions, which is included in this old mock:

A structural diff presentation similar to this has been implemented for Terraform v0.12, but the main reason I'm sharing this is to record the part related to service interruptions. In particular:

• This new ~!~ diff symbol is trying to succinctly represent the idea of a "disruptive update".
• The terminology is "service interruption" rather than "downtime" because it seems more general and thus can cover more cases without seeming weird.
• The specific change that is causing the service interruption is indicated, just like when a change "forces replacement" (or "forces new resource", as we would say in v0.11 and prior).

None of this is final by any means, but I just wanted to share this mock as a starting point for future design work. This requires both UI design work and protocol/API design work internally, so I expect (as Radek noted) it won't be doable for a while until some other work has settled down first. In particular, the initial v0.12.0 release and most likely also at least one phase of the SDK revamp to directly support the new v0.12 plugin protocol, so that we don't have to force this new idea through the old protocol shim layer.

[paultyng]

I think with 0.12 warnings (#74), we should be able to look at this.

[bflad]

Please note I created an issue upstream for tracking this as part of the protocol/UI, since it seems like a generic difference metadata implementation might be desirable to fulfill a few different but related use cases: https://github.com/hashicorp/terraform/issues/27550