getTopicQosProfile not reliable

[Flova]

In ros iron the QOS policy of the image proc nodes is currently determined by getTopicQosProfile with a default to the default sensor data qos policy. This is an issue, because during launch the incoming topic might not be available yet, so the sensor data qos policy is used. This causes downstream issues, because this qos policy is not compatible with reliable subscribers. So even if the input data has a reliable qos the output data might not in a non-deterministic way.

[Flova]

Also overwrites don't seem to be honored.

[mikeferguson]

These issues should be addressed by #847 - although only targeted at J-turtle currently. Backporting to Iron is going to be quite an effort since rolling/j-turtle have diverged so far from Iron at this point

[mikeferguson]

Finally digging into this again (as part of 847) - and after examining the API interfaces we actually have available in image_transport - here's the solution I'm working on:

• Subscribers will still have to use getTopicQosProfile since we can't pass QoS overriding to image_transport camera subscription function
• Publishers should never have used this function, all the publishers should be defaulting to reliable and supporting the override mechanism