Programmatically loading parameters from yaml files into nodes dynamically

Feature request

Programmatically loading parameters from yaml files into nodes dynamically

Feature description

A simple c++ function (possibly put into rclcpp::Node?) for loading parameters from yaml files after the node has been started. (ie. not via supplying a yaml file in the ros2 run command)

There were several ros1 repos using this functionality of loading nodes dynamically and supplying yaml file. However, the spec on parameters changed with ros2.

Implementation considerations

• Not sure if the function should be under rclcpp::Node.

• Some upcoming repos that could use this functionality:
  ros2_controls controller_manager loading controllers at runtime
  ros2 version gazebo_ros_controls (blocked)

• Reference code doing the same thing as this request that you could use:
  https://github.com/ros-controls/ros2_control/pull/64/files

• A good use case would be the following yaml file contains parameters for two nodes:

coffeebot_arm_effort_controller:
  ros__parameters:
    type: joint_trajectory_controller/JointTrajectoryController
    joints:
       - coffeebot_shoulder_pan_joint
       - coffeebot_shoulder_lift_joint
    constraints:
        stopped_velocity_tolerance: 0.05
        coffeebot_shoulder_pan_joint: {trajectory: 0.1, goal: 0.1}
        coffeebot_shoulder_lift_joint: {trajectory: 0.1, goal: 0.1}
    stop_trajectory_duration: 0.5

coffeebot_gripper_effort_controller:
  ros__parameters:
    type: joint_trajectory_controller/JointTrajectoryController
    joints:
      - coffeebot_gripper_left_joint
      - coffeebot_gripper_right_joint
    stop_trajectory_duration: 0.5

As far as I know it follows the spec given on the ROS2 tutorials

Start with the rclcpp::Node parameter APIs and the linked ros2_control pull request, then compare them with the ROS 2 parameter specification referenced in the issue. Resolve where the API belongs and how a YAML file containing parameters for multiple nodes should be handled after startup. Done means the behavior and public API are defined and covered by appropriate tests.