If the fsm is advanced while a task is holding a shared lock, and then
the task upgrades the lock to an exclusive lock, the fsm object for the
task still is in the old state. If the now-exclusive lock attempts to
(correctly)advance the state machine, it may explode, thinking it's in
the old state and the transition is invalid.
Use a getter/setter for self.node in the TaskManager object, so that
whenever we set a node object (like we do when upgrading a lock), the
fsm will be re-initialized and in sync with reality.
The task manager also still has a crutch for nodes in the NOSTATE
provision_state, for compatibility with Juno, which was to be removed in
Kilo, but nobody did. Instead of moving this crutch into the setter as
well, we remove it (and its unit test) here. We also update the unit
test nodes to use provision_state AVAILABLE by default, as around 1000
unit tests use the default and begin failing in the task manager if the
default is NOSTATE.
Last, we remove NOSTATE from states.ALLOWED_DELETE_STATES, as we should
never have a node in NOSTATE by now, and deleting the crutch causes the
test for this attribute to fail.
Change-Id: I0a0277742d512a8ad6e41f25d1c04c13fcf8d6a2
Closes-Bug: #1619232
88fc516678