feat: validate user input values the same way as "default"

[Emyrk]

No description provided.

[Emyrk]

@johnstcn @matifali should this pass a template import?

Before this PR, this would pass a terraform plan.

data "coder_parameter" "region" {
  name        = "region"
  description = "Which region would you like to deploy to?"
  type        = "string"
  order       = 1

  option {
    name  = "Europe"
    value = "eu"
  }
  option {
    name  = "United States"
    value = "us"
  }
}

This PR sets the error to:

Planning failed. Terraform encountered an error while generating this plan.

╷
│ Error: Value must be a valid option. The value is empty, did you forget to set it with a default or from user input?
│ 
│   with data.coder_parameter.region,
│   on main.tf line 21, in data "coder_parameter" "region":
│   21: data "coder_parameter" "region" {
│ 
│ the value "" must be defined as one of options

To fix this, either the value must be passed via an env var:

CODER_PARAMETER_c697d2981bf416569a16cfbcdec1542b5398f3cc77d2b905819aa99c46ecf6f6=us terraform plan

Or with a default:

data "coder_parameter" "region" {
  # ...
  default = "us"
  # ...
}

---

I feel like we should reject it? But that is a breaking change.

[matifali]

There are use cases where an admin may not want to set a default to force the user to choose an option. At least it was possible before this PR. I am not sure how many users were actually using it.

But I have seen requests to support coder_parameter without a default value better: #144

[johnstcn]

There are use cases where an admin may not want to set a default to force the user to choose an option.

This behaviour is problematic because you could end up with a plan that does not correspond to the apply, depending on how the value of the parameter is used.

Would marking the parameter as ephemeral be a possible workaround here?

EDIT: marking a parameter as ephemeral requires it to be mutable and to also have a default set. This may not suit certain use-cases.

[matifali]

Do we require a user input if the parameters are ephemeral? Do we not allow setting a default value for such parameters?
Do such ephemeral parameters support options too?

If the answers are yes, then we just need better docs on how to fulfill this use case.

So that people don't try to use the existing non ephemeral parameters.