Fix chained interfaces availability

[pac48]

Currently, if I send a request to start a chained controller (one that exports reference interfaces) and a controller that claims those exported reference interfaces, there is an error that the reference interfaces are Not available. This is caused by the fact ControllerManager::check_following_controllers_for_activate add the chained controller to to_chained_mode_request_, but before it can be activated on the realtime thread from ControllerManager::manage_switch, the activation requires is canceled because ControllerManager::prepare_command_mode_switch sees the required reference interfaces as unavailable. The solution in this PR is to mark the reference command interfaces as available during ControllerManager::check_following_controllers method and mark them unavailable if any other error occurs.

[codecov]

Codecov Report

Attention: 2 lines in your changes are missing coverage. Please review.

Comparison is base (786d5b5) 47.49% compared to head (1d9e91f) 47.50%.

Additional details and impacted files

@@           Coverage Diff           @@
##           master    #1369   +/-   ##
=======================================
  Coverage   47.49%   47.50%           
=======================================
  Files          41       41           
  Lines        3556     3560    +4     
  Branches     1938     1941    +3     
=======================================
+ Hits         1689     1691    +2     
  Misses        459      459           
- Partials     1408     1410    +2     

Flag	Coverage Δ
unittests	47.50% <50.00%> (+<0.01%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files	Coverage Δ
controller_manager/src/controller_manager.cpp	38.80% <50.00%> (+0.03%)	⬆️

[destogl]

@pac48, thanks for fixing this. I have checked and fixed this scenario. I would like to know why the tests didn't show this...

Can you add a test for this use case and then a fix? Just to be sure that we don't break this in the future.

[pac48]

Can you add a test for this use case and then a fix? Just to be sure that we don't break this in the future.
@destogl I will look into adding a test.