contributes an out-of-the-box durability profile

[BrannonKing]

Things like a map server benefit from a durable message (aka, send the last published map to each subscriber as they subscribe). We should have one of these in the default profile list, especially with talk of being able to select from canned QoS profiles using command line parameters.

[BrannonKing]

I assume that rclpy defines these as well and we would need a change there too?

Also, in thinking about it further I want depth 1 instead of depth 2. As this is typically used for large messages that change very infrequently, it is unlikely to benefit from a "finish sending that last one before this new one goes out" scenario.

[mikaelarguedas]

thanks @BrannonKing for the contribution. We will delay this until we iterated on how to do the equivalent of ROS 1 "latching" in ROS2.

[wjwwood]

Here's the issue we're using to track the latching decision: ros2/ros2#464

[paulbovbel]

Also, in thinking about it further I want depth 1 instead of depth 2

+1, this definitely makes sense for a 'default' durability profile, if approximating 'latched' behaviour from ROS1