[maven-release-plugin] prepare release workflow-0.1-beta-8
[maven-release-plugin] prepare for next development iteration
Broken Javadoc tags.
Updated beta 8 changelog to reflect late changes from @kohsuke.
Promoted the Outcome class over to the API

... as a preparation of providing StepContext after the body execution
Setting WorkflowRun.startTime and .duration.
Uses clock times, disregarding restarts and other pauses, so WorkflowJob.estimatedDuration is not likely to be accurate.
(Even more true for AfterRestartTask.)
Fixed messages around running build.
[JENKINS-25504] Trying to at least remove the trigger for the exceptions encountered when shutting down Jenkins.
Does not address the general possibility of the bogus NotSerializableException on Executor.
Does not have anything to do with actual interruption of an executor step
(as opposed to the InterruptedException thrown during shutdown).
Fixed display of progress bar in build history widget after a restart.
WorkflowRun.getExecutor is used by <t:buildProgressBar build="${build}"/>.
Comment about a display problem I do not know how to solve.
Thought I had still seen a bogus InterruptedBuildAction on a build that merely spanned a restart, but of course as soon as I add logging the problem becomes unreproducible.
You no longer need to import Java types just to configure enum-valued parameters in a step.
[JENKINS-25504]

Introducing BodyExecutionCallback as a beefed up version of
FutureCallback, so that the step implementation can interact with the
start body block / end body block, such as adding log messages.

We do this by creating a different StepContext objects that are only
valid during the body start and body end.  This in turn allow Steps to
re-inject the context to access correct TaskListeners and things like
that (which is not in this commit.)

Copying my email to jenkinsci-dev for the motivation:
------
I'm working on this card, where we want to be able to write to console
log and do stuff at the end of the body invocation.

The challenge here is that the Step API has no dependency to the
workflow Flow Node API (it goes the other way around), so we need to do
this in a way that doesn't force Flow API into the likes of RetryStep.
That pretty much means we need to do the context injection of
TaskListener like StepContext does.

I thought about two ways to do this.

One is to reuse the existing StepContext instance. We could just say
that at the point of the callback from the body execution,
StepContet.get() would return the context objects for the end of the
body (TaskListener connecte to the right FlowNode, etc.) We could then
provide some convenience base class that performs @StepContextParameter
injection, so that everything gets reinjected.

This works, but I also feel that it's bit brittle, especially for
ParallelStep that invokes multiple bodies at the same time, and thus it
wants multiple different post body execution context. So I started
thinking about another way, where the end of the body execution is
notified to FutureCallback<BodyExecutionResult> instead of
FutureCallback<Object>, and the newly added BodyExecutionResult class
would have properties like outcome, the same get(Class) method that
returns contextual object, and so on.

That also makes it more explicit that the context injection works
differently post body execution.
Trying to diagnose random failures in this test. (Observed on CI job and also locally, but not reproducible.)
Trying to diagnose a random failure in DSLTest.overrideFunction.
java.lang.NullPointerException
 at org.jenkinsci.plugins.workflow.cps.CpsStepContext.getThreadSynchronously(CpsStepContext.java:211)
 at org.jenkinsci.plugins.workflow.cps.CpsStepContext.doGet(CpsStepContext.java:272)
 at org.jenkinsci.plugins.workflow.support.DefaultStepContext.get(DefaultStepContext.java:64)
 at org.jenkinsci.plugins.workflow.steps.StepDescriptor.checkContextAvailability(StepDescriptor.java:115)
 at org.jenkinsci.plugins.workflow.cps.DSL.invokeMethod(DSL.java:132)
[JENKINS-25504]

CPS engine side of the change to fire newly added callbacks of
BodyExecutionCallback
For some reason WorkflowTest.acquireWorkspace suddenly started failing.
The cause seems to have been a race condition where a build is scheduled on a slave before onOnline is called.
Shuffling code between CpsBodyInvoker and CpsBodyExecution.

... to make their lifecycles clearer. Namely, CpsBodyInvoker is a builder pattern to accumulate
possibly non-serializable parameters, then once it gets going CpsBodyExecution represents
the running program state.

The time between CpsBodyInvoker.start() and CpsBodyInvoker.launch() is where two objects reside side by side.
Synced up with the 'master' branch

Conflicts:
	support/src/main/java/org/jenkinsci/plugins/workflow/support/steps/ExecutorStepExecution.java
BodyExecutionCallback provides the opportunity to interact with FlowNode, including adding Actions.

So I removed WorkflowBodyInvoker whose sole purpose was to add Actions to the start node.