rosmon_core: Adding fix for rosparam parsing to equivilate with undocumented behavior of roslaunch

[Cartoonman]

This was a really insidious and potentially controversial patch we needed to make to rosmon to handle some undocumented behavior of roslaunch.

The tl;dr is that roslaunch parses all <rosparam> tags before it parses all <param> tags. This is in contrast to what rosmon does:

	for(TiXmlNode* n = element->FirstChild(); n; n = n->NextSibling())
	{
                 .
                 .
                 .
		if(e->ValueStr() == "param")
			parseParam(e, ctx, PARAM_IN_NODE);
		else if(e->ValueStr() == "rosparam")
			parseROSParam(e, ctx);
		else if(e->ValueStr() == "remap")
			parseRemap(e, ctx);
		else if(e->ValueStr() == "env")
        }

This manifested itself as a really annoying bug when we were working with mavros. Specifically this launch file of theirs made the above difference matter.

We had setups running this file on roslaunch work with custom param inputs properly overriding the mavros frame_id namespaces. But when run on rosmon the custom param namespaces were not propagated, since in the above logic, the param fields got overridden by rosparam anyway.

I believe I did attempt a patch of simply moving rosparam above param but this did not solve the problem since the for-loop would still loop around params before reaching rosparam tags

The solution isn't great but it matches how roslaunch works, and shouldn't affect existing users.

[xqms]

Great, more roslaunch craziness :D

I don't particularly like roslaunch's behavior, but we have to match it. I guess almost all rosmon users use it in a dual-stack fashion together with rostest / roslaunch. Discrepancies are really bad.

Apart from the undocumented semantics, is there some other thing you don't like about your solution? I.e. do you think there is some technical issue which might bite us later on?

[Cartoonman]

Apart from the undocumented semantics, is there some other thing you don't like about your solution?

No, the only thing that irked me was that effectively I have to do two passes through the launch context to pull all rosparam tags, then fetch all the rest. This is a simple fix though, and trying to fold this into one for-loop is likely to increase the complexity more than necessary. Functionality-wise this should work fine and not affect downstream users.

[xqms]

Thanks!