Support optional variables

[JeanMertz]

Currently, all pipeline variables are required to be set before creating a task.

I've come across pipelines that could benefit from optional variables. For example, if your pipeline returns a large set of objects, and you want to allow the person running a pipeline to be able to filter those objects based on some extra variable.

You could add a {My Attribute Filter} variable, but now you are always required to provide a filter. You could then use (eventually) step templating (#23) combined with default variable values (#3) to (f.e.) ignore the filter if it's set to the * value, but that would make steps more complicated to implement and it makes it less clear when using a pipeline what the * is supposed to mean, requiring you to be more explicit about it in the variable description.

So instead, if we allow setting optional: true on pipeline variables, they are allowed to be empty. If you use these variables in the steps, a variable that isn't provided simply ends up as an empty string when using the variable (which might still require some templating to use, but I'm not sure there's a way around this).

By providing first-class support, we can also automatically convey the fact that this variable is optional in the UI, for example:

The "(optional)" part is added automatically.

---

Another way to achieve this is to use the default variable value feature (#3), and set the default to an empty string (""), which basically results in the same outcome. However, that feels like misusing the system, and it also prevents us from making it more explicit in the UI what is happening, so I'm leaning against that "hack".

[JeanMertz]

Given we now have #1 with different field types, we need to amend this proposal with a solution for non-text field types (such as radio buttons or select boxes).

I think it makes sense to make this change:

pub(crate) struct VariableConstraints {
    pub(crate) selection: Option<Vec<String>>,
+   pub(crate) required: bool,
+   pub(crate) optional_name: Option<String>,
}

In this case, you set a variable as required or not (defaulting to no, so you aren't required to provide this constraint when creating a variable), and then also provide an optional optional_name.

This optional name is what's used in a select box as the top-most option to represent "no value".

So for example, if my select box options are:

• Value 1
• Value 2

And I make this variable required: false and set optional_name: "No Value", then the options become:

• No Value
• Value 1
• Value 2

Clients can optionally add some styling to make the optional value stand out (grey it out a bit, add an icon to it, or wrap it in dashes such as -- no value --).

---

In the end, optional values together with select boxes aren't great, and you should avoid using them, but an optional value without select boxes is still useful to have.

Perhaps it makes sense to start with making the requirement constraint and selection constraint mutually exclusive, as that covers the most common use-case, and also makes it so we don't have to do all the above shenanigans of having an "optional name"?

As I'm typing, I'm leaning to; yes, let's make these two mutually exclusive and not deal with the added complexity for now.

[JeanMertz]

To put the above words into a more concise table:

selection set?	required set?	final required value
yes	yes	true
no	yes	true
yes	no	true
no	no	false

In other words: if you've provided a selection constraint, then the variable value is always required. If not, it depends on the required constraint (which defaults to false).

If you've defined a selection constraint and set the required constraint to false, the server will return an error.