Skip Model SDF serialization

[iche033]

🦟 Bug fix

Related gazebosim/sdformat#1478

Summary

Skip model sdf serialization. The main problem is actually in the perf of deserialization (root.LoadSdfString), see gazebosim/sdformat#1478. This change returns an empty string in the Serialize function which will cause the Deserialize function to just skip trying to load the sdf string.

Testing with the Jetty demo world, the reduced load time from 55s to 42s and resuming from paused state (ie hit Play button) is now almost instantaneous.

Checklist

• Signed all commits for DCO
• Added tests
• Updated documentation (as needed)
• Updated migration guide (as needed)
• Consider updating Python bindings (if the library has them)
• codecheck passed (See contributing)
• All tests passed (See test coverage)
• While waiting for a review on your PR, please help review another open pull request to support the maintainers
• Was GenAI used to generate this PR? If so, make sure to add "Generated-by" to your commits. (See this policy for more info.)

Generated-by: Remove this if GenAI was not used.

Note to maintainers: Remember to use Squash-Merge and edit the commit message to match the pull request summary while retaining Signed-off-by and Generated-by messages.

[azeey]

We can remove all the code in here as well since we know we won't be deserializing anything.

[arjo129]

I'm curious what completely removing serialization breaks. Do we have any downstream systems that use this model info?

[iche033]

Currently the physics and entity_semantics systems use ModelSdf component but these systems live on the server side so do no depend on serialization / deserialization. No GUI plugins in Gazebo currently use this component. However, if users writing their own GUI plugins depend on the ModelSdf component, this will break their code. Similarly, users keeping a copy of their own ECM will also also be affected by this change.

[iche033]

I have an alternative workaround in #3082. That PR does not break any existing behavior. It improves the load time but just not as much as this PR.