Add new API to store input parameter info separately from the execution

[svanoort]

Very basic version of what I describe in #2 (comment) -- doesn't bother to move some logic to the InputAction that could be.

Attaches information about input prompts on a run to the InputAction (persistently) and provide new APIs to access it. Since most of the external calls to the InputAction are looking to see what input is needed in order to display UI notifications, these APIs should handle this without the risk of deadlock/long wait fetching executions. Should be faster too.

Since older builds won't have the field, we handle null and generate generate the data from the executions when we read or modify them.

CC @jglick to see what you think. I'm probably missing some things here but I want to see if the idea is sound before investing more time to polish it up & test. Should be compatible with #2 as well (just needs that merged in).

There's some sort of small FindBugs complaint about inconsistent synchronization behavior of the run there (shrug), but that's not such a big deal at the moment.

[jglick]

Still have failures in InputStepTest.test_cancel_run_by_input and InputStepTest.parameter.

[jglick]

So what is the purpose of this class? AFAICT we could just save InputStep as is (which is what InputStepExecution does).

[svanoort]

@jglick Is InputStep safe to use as an API response object on its own? Safe to serialize/deserialize without carrying along context, etc? I didn't see anything explicitly preventing this, but wasn't sure about the implication of passing around & persisting naked steps.

[jglick]

The idea looks sound, but this PR is incomplete in that it does not show the new API actually being used from the stock UI code. (Obviously a downstream PR showing it being used in stage view would help verify the design as well.)

[jglick]

Also I would expect to be able to make InputStepExecution.input be transient: loaded from serial form for old builds, but for new builds not used after start, with the metadata being kept in InputAction instead (otherwise we are duplicating everything). That of course means that various methods like parseValue would need to have an InputStep passed in externally. Really all the web methods in InputStepExecution like doProceed should be deprecated, delegating to new methods in InputAction. So I think we are looking at a bigger rewrite.

[jglick]

See JENKINS-37998.