dartsim 7 on main branch depends on Jetty version of libsdformat

[scpeters]

The libsdformat parser is added as a dependency of dartsim in dartsim/dart#2154 (main branch, which will be major version 7), and version 16.0 of libsdformat appears to be a required dependency of the dart-utils component.

This may have packaging implications.

[traversaro]

The libsdformat parser is added as a dependency of dartsim in dartsim/dart#2154 (main branch, which will be major version 7), and version 16.0 of libsdformat appears to be a required dependency of the dart-utils component.

This may have packaging implications.

We have a similar situation in iDynTree: gbionics/idyntree#1269 , but clearly that is easier as idyntree is not in the dep chain of gazebo, even if we want to still be able to co-install idyntree with any (supported) version of gz-sim . At the conda-forge level, my plan is to provide two variants of iDynTree, one with SDF support enabled, and one with SDF support disabled, so that users will get the variant without SDF support disabled if they install gz-sim that requires an incompatible version of sdformat, and that is something we could also do with dart. However, I am not sure if such strategy can be easily replicated on other package managers (unless we just disable sdf support in dart).

[jslee02]

Could conda global pinning help here? We could also add version constraints in gz-physics and dart for the compatible SDFormat versions?