proposed break: change non-interactive prompt behaviour

Summary

This is a proposed breaking change.

I count five places where we assume choices on behalf of the user when we're non-interactive:

1. Element failure. This is controlled by scheduler.on-error in buildstream.conf.
2. SIGINT, we assume the user chooses 'terminate'.
3. Not being able to find project.conf, we assume the user chooses not to create a project.conf.
4. bst reset, we assume the user chooses 'yes' when asked if they are sure.
5. bst workspace close --remove-dir, we assume the user chooses 'yes' when asked if they are sure.

I think (4, 5) changing their behaviour when non-interactive is surprising. They go from 'safe' when interactive to 'unsafe' when non-interactive. That being said, inverting the non-interactive behaviour would be silly - if they were 'safe' when non-interactive then they wouldn't do anything, and wouldn't be scriptable.

We are looking to configure the interactive behaviour of (3, 4, 5) with prompt.* options in buildstream.conf with !887 (merged).

In #726 (closed), we also consider introducing --assume-yes and -y options for (4, 5).

When both of those changes are made, it seems to me that for (4) and (5) we will have a chance to change the behaviour to stay useful and yet also be unsurprising. It would be a breaking change however.

Relevant logs and/or screenshots

• MR for prompt.* options: !887 (merged)
• Issue for overriding 'are you sure?' prompts: #726 (closed)

Possible fixes

When prompt.workspace-close-remove-dir is set to ask and the user does not specify --assume-yes, then bst workspace --remove-dir should exit with an error if non-interactive.

The same goes for prompt.workspace-reset and bst workspace reset.

This would be a change in behaviour for folks that upgrade BuildStream without changing any arguments or config options - scripts that work now with (4, 5) would break.