Dinamically load maliput backends.

[francocipollone]

Context

We are linking to maliput_dragway, maliput_multilane and maliput_malidrive. When any of these backends change delphyne must be recompiled.

We could benefit from using the Maliput Plugin architecture

Victory Condition

Use Maliput Plugin architecture to create a maliput::api::RoadNetwork for any of the maliput implementations.

[francocipollone]

Switching to use the maliput plugin architecture will demand the following:

• 1. Delphyne won't depend on maliput_dragway, maliput_multilane and maliput_malidrive.
• 2. road_builder.h methods' implementations should use the plugin architecture instead. (CreateDragway(), CreateMultilaneFromFile(), CreateMalidriveFromXodr(), CreateMalidriveRoadNetworkFromXodr(), CreateOnRamp())
     • As the maliput::plugin::RoadNetworkLoader interface's operator returns a maliput::api::RoadNetwork some of those methods that nowadays returns maiput::api::RoadGeometry should be modified.
     • This will imply minor modifications on the .py files that use the bindings as now will return a RoadNetwork.
     • There is one method(CreatesOnRamp) that creates a RoadGeometry using the MultilaneOnRampeMerge class. In order to avoid this I see two options:
     • A: Given that CreateOnRamp method only uses the default values for building the "OnRamp" we could provide a yaml file with the RoadGeometry description using the default values and the CreateOnRamp method would consume that.
     • B: Create another maliput::plugin::RoadNetworkLoader plugin that creates a RoadGeometry based on a MultilaneOnRampeMerge.
• 3. Some tests are using the maliput::multilane::Builder class to build a maliput_multilane road geometry without using a yaml file.
     • One alternative of this is creating a yaml file in maliput_multilane with the same road geometry there described to be used in the test. (road_path_test.cc, traffic_pose_select_test.cc, pure_pursuit_test.cc ). Or just adding those yaml files in the test folder in delphyne just to be used for test purposes.
• 4. This will impact downstream at delphyne_gui for the MaliputViewerPlugin.

[francocipollone]

We could improve the maliput_multilane plugin to be able to handle different implementations depending on the parameters that are provided. That way the plugin will choose between:

• Load it from a yaml file.
• Load it from a yaml string. --> Solve the (iii) issue in the delphyne tests.
  • In the tests a yaml string will be passed representing the same RoadGeometry built with the maliput::multilane::Builder.
• Use MultilaneOnRampeMerge builder --> Solve the (ii) item in the CreateOnRamp implementation