Fixed lifecycle manager startup (#2917)

[robotechvision]

---

Basic Info

Info	Please fill out this column
Ticket(s) this addresses	#2917
Primary OS tested on	Ubuntu
Robotic platform tested on	Tested by @AlexeyMerzlyakov

---

Description of contribution in a few bullet points

• Fixed lifecycle manager startup failure with FastRTPS which was caused by an rclcpp bug whose fix hasn't been merged yet

Description of documentation updates required from your changes

• No updates needed

---

Future work that may be required in bullet points

• Can be reverted after Fix bug that a callback not reached ros2/rclcpp#1640 has been merged

For Maintainers:

• Check that any new parameters added are updated in navigation.ros.org
• Check that any significant change is added to the migration guide
• Check that any new features OR changes to existing behaviors are reflected in the tuning guide
• Check that any new functions have Doxygen added
• Check that any new features have test coverage
• Check that any new plugins is added to the plugins page
• If BT Node, Additionally: add to BT's XML index of nodes for groot, BT package's readme table, and BT library lists

[mergify]

@robotechvision, please properly fill in PR template in the future. @SteveMacenski, use this instead.

• Check that any new parameters added are updated in navigation.ros.org
• Check that any significant change is added to the migration guide
• Check that any new features OR changes to existing behaviors are reflected in the tuning guide
• Check that any new functions have Doxygen added
• Check that any new features have test coverage
• Check that any new plugins is added to the plugins page
• If BT Node, Additionally: add to BT's XML index of nodes for groot, BT package's readme table, and BT library lists

[SteveMacenski]

Can be reverted after ros2/rclcpp#1640 has been merged

Is there a benefit to having it the other way? To be fair, I more or less skimmed the thread, it seemed like you and Alexey were doing a good job at figuring this out. The impression I got was that it doesn't really matter to us.

[AlexeyMerzlyakov]

Is there a benefit to having it the other way?

Current PR is intended to make service_thread_ to work correctly. This will make to create/maintain new service thread from the same thread where (and right after) the timer callback for this thread was declared: in the right place where it should be even if ros2/rclcpp#1640 to be fixed. So, in my opinion this is so we should have in Nav2 anyway (without future reverting after rclcpp PR to be fixed).