Update RabbitMQ settings (again)

[1468ca0b-2a64-4fb4-8e52-ea5806644b4c]

Created by: vvv

We don't want one RabbitMQ queue to have several consumers, because there seem to be no (simple) way for a consumer to cherry-pick messages from the queue.

The issues we've uncovered while using the single queue approach:

• Halon put a message (SMART test request) into the queue, but SSPL - the intended recipient - did not receive it. Halon was not only producing messages for that queue but also consuming messages from it. So it happened that Halon got that message first. Consumed message gets dequeued.

• sspl-ll-cli --simulate <serial> --event DRIVE_UNINSTALL put a message into the queue. The intended recipient (SSPL again) didn't get the message, because Halon caught it first (again).

Note that in both cases Halon was consuming ActuatorRequest messages, which Halon's msgHandler cannot parse (it expects SensorResponse or ActuatorResponse). Halon printed "Unable to decode JSON message: " to systemd log.

Also in the patch:

• Helper.Runner (run'): Refactor.

[1468ca0b-2a64-4fb4-8e52-ea5806644b4c]

Created by: vvv

Superseded by #1465.

[1468ca0b-2a64-4fb4-8e52-ea5806644b4c]

Created by: vvv

@andriytk Thank you for questioning this patch.

Indeed, there are four threads in halond implementation:

binding	direction	messages consumed	where new thread is spawned
sensor	incoming (from SSPL)	SensorResponse, ActuatorResponse	startSensors
iem	outgoing (to SSPL)	InterestingEventMessage	startActuators.iemProcess
cmd	outgoing	ActuatorRequest	startActuators.commandProcess
cmdAck	incoming	ActuatorResponse	startActuators.replyProcess

[1468ca0b-2a64-4fb4-8e52-ea5806644b4c]

Created by: andriytk

Are we sure that IEM, Sensor Message and Actuator Acks consumers are running in the same thread? Because if not, the right messages may be delivered to the wrong consumers, I'm afraid.

BTW, why just not revert back to the old code where each consumer has its own queue?

[1468ca0b-2a64-4fb4-8e52-ea5806644b4c]

Created by: vvv