configs: explicitly nullable variable values

[jbardin]

The current behavior of module input variables is to allow users to
override a default by assigning null, which works contrary to the
behavior of resource attributes, and prevents explicitly accepting a
default when the input must be defined in the configuration.

Add a new variable attribute called nullable which will allow explicitly
defining when a variable can be set to null or not. The current default
behavior is that of nullable=true.

Setting nullable=false in a variable block indicates that the variable
value can never be null. This either requires a non-null input value, or
a non-null default value. In the case of the latter, we also opt-in to
the new behavior of a null input value taking the default rather than
overriding it.

In a future language edition where we make nullable=false the default,
setting nullable=true will allow the legacy behavior of null
overriding a default value. The only future configuration in which this
would be required even if the legacy behavior were not desired is when
setting an optional+nullable value. In that case default=null would
also be needed and we could therefor imply nullable=true without
requiring it in the configuration.

The possible combinations of variable configuration are:

# Variable must be set, but may be explicitly set to null.
# In this case, the module author must deal with var.a possibly being null
variable "a" {
  nullable = true
}

# Variable may be omitted, in which case it takes on the default, or may be
# explicitly set to null in which case it appears as null
# In this case, the module author must deal with var.b possibly being null
variable "b" {
  nullable = true
  default  = "hello"
}

# Optional variable where null is allowed. `nullable=true` is default now, and
# may be inferred in the future from `default=null` value when `nullable=false`
# becomes the default, so setting nullable here should never be required.
# In this case, the module author must deal with var.b possibly being null
variable "c" {
  nullable = true
  default  = null
}

# Non-nullable with a default: if left unset, or set explicitly to null, then
# it takes on the default value
# In this case, the module author can safely assume var.d will never be null
variable "e" {
  nullable = false
  default  = "hello"
}

# Non-nullable with no default: variable must be set, and cannot be null.
# In this case, the module author can safely assume var.d will never be null
variable "e" {
  nullable = false
}

# Non-nullable with a null default: an invalid combination, because a non-nullable
# variable can never be null
variable "f" {
  nullable = false
  default  = null
}

Fixes #24142

[apparentlymart]

I didn't have time yet to read through all of this because I have a meeting shortly but I wanted to just share the one comment I already left inline here, in case it's helpful in the meantime, and then I'll come back and read more of this a bit later if someone else doesn't get there first!

What I read so far looks good, though!

[alisdair]

I like this revised design a lot! There was one part inline that I'm a bit confused by. I think we'll need a docs update for this too.

[apparentlymart]

Looks good to me!

[jbardin]

I'll follow up with a separate PR for docs

[github-actions]

I'm going to lock this pull request because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active contributions.
If you have found a problem that seems related to this change, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.