Avoid unnecessary sets of GUID_t

[MiguelCompany]

While debugging the test failures on ros2/ros2#1241, I discovered we could directly keep the publisher and subscription counts instead of keeping a set of GUID_t.

This PR does just that.

[clalancette]

Looks reasonable to me. I'll go ahead and run CI on it.

[clalancette]

CI:

• Linux
• Linux-aarch64
• Windows

[fujitatomoya]

@MiguelCompany this PR looks good to me (using current count from dds), but i am not sure why this can fix the problem. Using GUID list based on handles, why it cannot work in the same way with this PR?

[clalancette]

We can ignore the Windows failure; that is due to a separate issue that has since been fixed. We can rerun that later.

However, there are a lot of new failures in Linux and Linux aarch64 with this PR in place. @MiguelCompany can you take a look?

[MiguelCompany]

@clalancette I only tested this against the master branch of Fast DDS, as I was debugging ros2/ros2#1241.

It seems current_count is not working properly on branch 2.3.x. I can leave this open till we have fixed that on Fast DDS 2.3.x, so it can later be backported into Galactic.

After we change rolling to use Fast DDS master though, I would use a different approach I have on a local branch, in which the DataReader and the DataWriter are directly queried for the match count.

[clalancette]

@MiguelCompany Now that we have ros2/ros2#1241 merged, feel free to revise this PR to what you think it should be, or open a new one with your new approach. Then we can run CI again.

[MiguelCompany]

@clalancette Thanks. I've just pushed the new approach, in which the matched counts are directly obtained from Fast DDS.

[MiguelCompany]

@clalancette Friendly ping

Sorry, I just saw this has conflicts. Will rebase tomorrow

[fujitatomoya]

@MiguelCompany can you rebase this when you have time?