Fix workers state changing behaviour
Changing state to IDLE (with key generation) or to MAINTENANCE is
a time consuming operation. That's why new workers' states are
introduced:
* PREPARE - when entering IDLE;
* BUSY - when entering MAINTENANCE.
Without them, state of workers can be changed during these long
operations as another method call can change the worker state
or initiate another long operations breaking actual state of workers.
To fix this issue not only new states are introduced, but also
an additional goroutine for every registered worker is started.
The goroutine is responsible for running long operations
in background. It is controlled with a channel through which
new worker state is sent every time setState is called.
The goroutine breaks execution of current long operation if new
state is set for worker.
As new states appear some changes in workers' methods behaviour
needs to be changed:
* SetFail returns ErrInMaintenance also for BUSY state
(formerly for MAINTENANCE only).
* SetState ignores attempts to set MAINTENANCE when worker is BUSY
and to set IDLE when worker is in PREPARE because requested
state changes are already in progress.
* PrepareWorker is allowed to be run only for workers in RUN state.
This method is used in two cases: when Job is finished
or when matching of reserved worker and request fails to create
the Job. In both cases worker should be bring to IDLE state
only if if it was in RUN state. If it was in MAINTENANCE
or FAILED it should be kept that way.
* OnWorkerFail is sent when worker's Job was interrupted (if it was
in RUN state, and enters any other than IDLE or PREPARE states).
Naming of methods parameters has been unified. All methods running
for a boruta.WorkerUUID use uuid variable and a worker variable
is used for mapWorker structure.
Change-Id: I8d1d8b55e48e432746ebf819650a77698b8c27ab
Signed-off-by: Lukasz Wojciechowski <l.wojciechow@partner.samsung.com>