Always modify UserObjectQosPolicy regardless of override policy

[asorbini]

This PR updates rmw_connextdds to always modify DomainParticipantQos::user_object (as introduced by #25) regardless of the participant QoS override policy requested by the user (introduced by #41).

This is required to let the participant be shared with applications using Connext's C++11 API, even when they use policies basic or never. In these cases, applications would not be able to properly use the participant because UserObjectQosPolicy cannot be modified from XML:

RTIXMLParser_validateOnStartTag:Parse error at line 263: Unexpected tag 'user_object'

The change is trivial, since it only consists of moving a block to the beginning of rmw_connextdds_initialize_participant_qos_impl().

[asorbini]

Since this PR has no functional impact wrt/unit testing when compared to #25 and #41 (because the differences only occur when RMW_CONNEXT_PARTICIPANT_QOS_OVERRIDE_POLICY is set to a value other than all), I'd like to merge it without running CI to save some time, but if we want the "checkbox marked", then I'll start the plans.

@ivanpauno is this allowed by the process?

[ivanpauno]

Since this PR has no functional impact wrt/unit testing when compared to #25 and #41 (because the differences only occur when RMW_CONNEXT_PARTICIPANT_QOS_OVERRIDE_POLICY is set to a value other than all), I'd like to merge it without running CI to save some time, but if we want the "checkbox marked", then I'll start the plans.

@ivanpauno is this allowed by the process?

I agree that there's no functional impact in this PR.
I typically run at least CI in one platform with colcon build ... --packages-up-to rmw_connextdds_common colcon test ... --packages-select rmw_connextdds_common, to check that everything still builds/linters still pass (I used rmw_dds_common in the commands as an example, I write there the list of packages affected by the PR).

[asorbini]

Quick CI validation (Linux, build --packages-up-to rmw_connextdds, test --packages-above rti_connext_dds_cmake_module):

[ivanpauno]

--packages-up-to rmw_connextdds, test --packages-above rti_connext_dds_cmake_module

test --packages-above rti_connext_dds_cmake_module failed here because it's trying to run tests in packages that weren't built.
You have to make sure that the packages selected in the test command are a subset of the ones selected in the build command (which can be a bit confusing sometimes).

Linux

edit: Passing to colcon graph/list locally the same "package selection" flags might help to understand which packages are being selected.

[asorbini]

Oops, thank you for running with the right arguments, I see the issue now. I tried to be "slick" but I was definitely too quick :)

I think I could have used --packages-above rti_connext_dds_cmake_module --packages-up-to rmw_connextdds to just test the packages from ros2/rmw_connextdds.

Anyway, since things are green I'll go ahead and merge this PR.