Layered handling of node and (sub-)system errors

还没有人认领这个 Issue。

from (#47 )

> This is in the context of our exemplary case of the `laser_driver` error. We want to elaborate on the **layered** approach we discussed in the last MROS meeting. This is how I interpret our desired design (please comment if something is not correct or clear):
> 1. First the `laser_driver` code for handling errors tries to recover from the error in the `ErrorProcessing` transition state.
>
> _(from here it is a related but different issue)_
>
> 2. If it does not succeed (I guess that means node does not transition to `Active`), the `ModeManager` tries to recover from the error using the `feature/rules`. For this, @jginesclavero is adding a rule in the SystemModes file of our system.
> 3. If there is no rule, or there is but after applying it the alternative `MODE(s)` of the `laser_driver` are not reached either, the `ModeManager` reports to the `MROS Metacontroller` that the corresponding (sub)system(s) MODE(s) are not reachable.
> (see issue for the continuation of the handling of errors at the higher layers)

_continuation_

Currently this will be implemented in a passive way, by offering that information (see https://github.com/micro-ROS/system_modes/issues/43)
But, since the current target `MODE` cannot be reached... we were thinking (in a discussion with TUD and URJC) if the `ModeManager` should report this **actively** system wide, for the operator or any supervisory system (e.g. `MROS Metacontroller`) to handle it.

**Proposal**: Since not being able to reach the target `MODE` is a deviation of expected and desired behaviour, we propose that the `ModeManager` uses `diagnostics` to report this. The `MROS Metacontroller` will subscribe such diagnostic messages.
(@fmrico @jginesclavero @marioney please comment if I missed something or did not convey it correctly)

What do you think @norro ?

首先阅读 issue #43，以及关于 ModeManager、diagnostics 和 MROS Metacontroller 的讨论。文中没有指定源文件或测试，并且在实现可以被视为完成之前，还需要就诊断接口和预期行为达成一致。

由索引模型根据 Issue 内容生成。