Revert behavior of FilePath() for elements loaded from strings

[azeey]

🦟 Bug fix

Summary

#548 introduced a behavior change on sdf::Element::FilePath() for elements loaded from strings. Before that PR, FilePath() returned "" for such elements, but presently, it returns either data-string or <data-string>. This behavior change could cause failures in downstream applications once released (I know the test INTEGRATION_save_world in ign-gazebo will have test failures).

4876f92 adds failing test showing the behavior change.

Checklist

• Signed all commits for DCO
• Added tests
• Updated documentation (as needed)
• Updated migration guide (as needed)
• Code check passed (In source directory, run sh tools/code_check.sh)
• 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

Note to maintainers: Remember to use Squash-Merge

[azeey]

FYI @aaronchongth from d3798f6

There were two test failures:

1. When a nested model is parsed, it's file path is not properly
   propagated from the parent element. In fact, the nested model is
   removed from its parent via RemoveFromParent(). This is probably a
   bug in itself which requires further investigation. For now,
   explicitly setting the FilePath() is necessary

2. Plugin elements were being treated differently than other override
   elements such as name and pose when SetFilePath() was called on
   them instead of inheriting the file path from their parents. Updating
   the test expectations fixed the failure.

[aaronchongth]

Thanks for reverting the behavior and highlighting these bugs!

The fix for (1) makes sense, thanks!

For (2), I chose to set the file path of the plugin element explicitly to the file where it was defined, instead of following what was done for name and pose, as it seems more intuitive for debugging. It might be slightly confusing if the users head over to actorFIlePath but the plugin element was missing. Names and poses are overriding instead of additive, so inheriting the file path from the included file makes sense. 🤔 Let me know what you think.

[azeey]

From the debugging perspective I think it is useful to have plugin have a file path to where it was defined as you pointed out, but this is true for name and pose as well. But there's another perspective, which is the use of the file path of these elements to determine the file path of other items. For example, a plugin might look for auxiliary files such as meshes or textures in the directory containing the included model. In order for such plugins to continue to work and since this is a stable release version, I think we should preserve the existing behavior.

[aaronchongth]

Thanks for explaining. In that case, having the same behavior for all overriding elements makes sense. Thanks for the fixes!

[adlarkin]

It looks like the INTEGRATION_save_world test in ign-gazebo is passing now 👍

When a nested model is parsed, it's file path is not properly
propagated from the parent element. In fact, the nested model is
removed from its parent via RemoveFromParent(). This is probably a
bug in itself which requires further investigation.

Should we ticket an issue for this?