Remove Controller assertions and return errors instead

[frankmcsherry]

This PR changes the return type of Controller methods to present errors in cases the controller would panic due to dynamically verified constraints (e.g. all identifiers present, since frontiers are valid, etc).

All previous uses of these methods simply unwrap() their results, panicking just as they would before. However, there is now the possibility of some remediation whereas there would not be otherwise. The methods validate the transition before they take them, so that if an error is returned the command had no effect.

These validation steps could likely be broken out to independent methods to allow users (@mjibson, @sploiselle) to validate commands before launching them. We can do that in follow up work if it would be useful, but didn't want to overdo it here.

Motivation

• This PR refactors existing code.

The coordinator was at the mercy of the Controller to determine what commands would work and which would not. Ideally this gets us closer to clearer communication and less guessing.

Checklist

• This PR has adequate test coverage / QA involvement has been duly considered.
• This PR adds a release note for any user-facing behavior changes.

[antiguru]

Looks fine

[sploiselle]

I have a dumb question, and sorry if I am behind everyone else's understanding: is instance equivalent to CLUSTER?

[frankmcsherry]

@sploiselle instance is the rock-solid internal name for things that COMPUTE and STORAGE each spin up ("compute instance" and "storage instance"). No one could agree on what the user-facing name would be, so we agreed to use these internally and let the user names bind whenever folks manage to finish up their extended theses with supporting figures and graphs. You can use CLUSTER and be understood for sure, but I don't use it in case we change it to BANANA while I'm not looking.