support fail fast for node removal

[car-roll]

jenkinsci/workflow-durable-task-step-plugin#372 added fail fast for cloud node removal. However, this feature is not supported by the ec2 plugin.

This PR refactors EC2AbstractSlave and EC2Computer in order to take advantage of jenkinsci/workflow-durable-task-step-plugin#372

Testing done

• Perform manual testing by killing spot instance manually and watching startup

Submitter checklist

• Make sure you are opening from a topic/feature/bugfix branch (right side) and not your main branch!
• Ensure that the pull request title represents the desired changelog entry
• Please describe what you did
• Link to relevant issues in GitHub or Jira
• Link to relevant pull requests, esp. upstream and downstream changes
• Ensure you have provided tests - that demonstrates feature works or fixes the issue

[jglick]

Failing in CI.

[car-roll]

Yeah, this one is mystifying me. I'm still trying to figure out why

[jglick]

(ignore WS)

[jglick]

Looks right, but has it been tested?

[car-roll]

Cannot read field "terminateScheduled" because "node" is null
Comparing the test logs from master and this PR, everything looks similar up until the very end. Both versions show the ec2 instance idle timeout and terminated/removed, but then this version has this error that the node is null. I guess something funky is going on with this version's terminate. Terminated too soon maybe?

[jglick]

Regarding #998 (comment) I guess that

ec2-plugin/src/test/java/hudson/plugins/ec2/EC2RetentionStrategyTest.java

Lines 759 to 760 in 753e04a

	EC2AbstractSlave node = c.getNode();
	assertTrue(node.terminateScheduled.await(10, TimeUnit.SECONDS));

was not right to begin with (Computer.getNode may return null if the agent definition has been removed from the system before the executor is released and the computer destroyed) but happened to pass before due to different timing conditions. It is not exactly clear to me what the test is supposed to be asserting here. I guess you could just skip the last assertion in case node == null since this would be normal if the build is finishing.

[car-roll]

closing in favor of #1015 due to the branch conflicts

[jglick]

For the future, please retain the same PR and just resolve conflicts in it. In the worst case, if running a merge tool became completely unwieldy and it was really easiest to start from scratch, just reset your branch to origin/master, reapply changes, and force push. At least the context of previous reviews is retained.

[car-roll]

@jglick yeah I was having a terrible time with the merge conflicts but I didn't think about force pushing. Will do that next time.