Implement matched event

[Barry-Xu-2018]

Implement the feature about ros2/rmw#330

[Barry-Xu-2018]

@gbiggs @sloretz
While I change code, I have a question about below codes

rmw_fastrtps/rmw_fastrtps_shared_cpp/src/rmw_wait.cpp

Lines 191 to 205 in ccea7a3

	if (ReturnCode_t::RETCODE_OK == ret_code) {
	eprosima::fastdds::dds::Entity * entity = status_condition.get_entity();
	eprosima::fastdds::dds::StatusMask changed_statuses = entity->get_status_changes();
	if (changed_statuses.is_active(
	rmw_fastrtps_shared_cpp::internal::rmw_event_to_dds_statusmask(
	event->event_type)))
	{
	active = true;
	}
	if (guard_condition.get_trigger_value()) {
	active = true;
	guard_condition.set_trigger_value(false);
	}
	}

Could you explain what cases need double-check for active ?
I want to modify it (Please refer to my change in rmw_wait.cpp) since 2 RMW events is corresponding to one DDS event for implementation.

[ivanpauno]

first review

[Barry-Xu-2018]

Updated code based on review comments.
Now remain one comments #645 (comment)

[Barry-Xu-2018]

do rebase.

[fujitatomoya]

some minor comments need to be resolved.

[fujitatomoya]

lgtm

[fujitatomoya]

@iuhilnehc-ynos can you have another look on this?

[iuhilnehc-ynos]

It's better to add a comment to explain why we add these codes.

[Barry-Xu-2018]

Yes. I should add explanation for the change.

[iuhilnehc-ynos]

I don't know if it's the correct way to use them, but it looks good to me overall.

I just wondered something as below,
What if there is a requirement about adding matched status event based on the DDS feature in the future? Do we need to update the whole related PRs?

I mean if we don't add the one only matched status event, we should not use the name matched status in rmw.

[Barry-Xu-2018]

I just wondered something as below, What if there is a requirement about adding matched status event based on the DDS feature in the future? Do we need to update the whole related PRs?

I mean if we didn't add the matched status event, we should not use the name matched status in rmw.

Current rmw matched status is redefined based on DDS matched status definition for the convenience of user understanding.
If introduce original DDS matched status, maybe we can use dds_matched_status.

[iuhilnehc-ynos]

It's weird for me to define a unmatched_status with a structure named PublicationMatchedStatus.
Can we use the structures defined in the rmw directly?

Currently, there are two separate calculations in both on_*_matched and take_event for unmatched_status.
Can we just update the final data in on_*_matched?

[Barry-Xu-2018]

Can we use the structures defined in the rmw directly?

Yes. Need not use eprosima::fastdds::dds::PublicationMatchedStatus.

Currently, there are two separate calculations in both on_matched and take_event for unmatched_status.
Can we just update the final data in on_matched?

Yes. I will optimize code.

[Barry-Xu-2018]

Now interface is changed. We only use matched event in rmw layer (ros2/rmw#331).
So code changes are quite significant.
Besides, merged implementation of inconsistent topic leads to many conflicts with old commits while doing rebase.
So I will merge all commits in this PR to one commit and then do rebase.

[Barry-Xu-2018]

Check failure is because rmw package is old in CI environment.