Parallel asset download

[nkoenig]

Fixes: #1260

🎉 New feature

Summary

This will download simulation assets in background threads by default. You can force simulation to wait for assets using the --wait-for-assets CLI option. I'm defaulting to async download because:

1. It's a better user experience to have some instant GUI feedback.
2. If you're using only the simulation server (no GUI), then you're in the experienced user category and can choose whether to wait for assets or not.

Test it

1. Clear(or stash) your ~/.gz/fuel directory, and load a world with many assets asynchronously:

gz sim -v4 tunnel.sdf

1. Try the same thing, but with blocking asset download:

gz sim -v4 --wait-for-assets tunnel.sdf

4. Try the same thing, but specify a certain number of iterations:

gz sim -v4 --iterations 10 tunnel.sdf

Checklist

• Signed all commits for DCO
• Added tests
• Added example and/or tutorial
• 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.)

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.

[arjo129]

Thank you for this! This is such an amazing (and much needed) improvement in User Experience! I only have a handful of minor code-related knits.

It'd also be great if we could follow this up with some form of signalling, so that the GUI client can at least be aware of the state of the download.

[arjo129]

Knit: I think its perfectly safe to remove this. It seems we no longer use this inside ServerPrivate and this is the only mention in Server.cc. While the copy constructor for SdfRoot has been optimized recently, this is still an unessecary operation.

[azeey]

We mainly want to keep the sdf::Element shared pointers valid since they will be used by systems to configure themselves. Some of these plugins might traverse to their parent elements via a weak pointer. If the sdf::Root object is destroyed, it could cause these shared pointers to become invalid.

I do think we should use a pointer here to avoid the extra copy, but that could be a followup PR.

[arjo129]

Knit: Remove space

[azeey]

Fixed in 17834d5

[azeey]

I think the homebrew test failures are due to a type mismatch on component IDs between gz-sim and gz-msg. See gazebosim/gz-msgs#529

[azeey]

Haven't done a full review, but can confirm it works as described.