Add message lost event

[ivanpauno]

See #226.

First commit reorganizes event statuses headers in a subfolder, so we stop populating the old big rmw/types.h (the old headers are still including the new ones, to avoid creating a bunch of PRs together with this one).

The second commit actually implements what the title says.

[jacobperron]

I'm happy if we distribute the event status definitions into their own header files, but I think it would be best done in it's own PR as it seems completely orthogonal to adding a new event type. At the very least, we should update this PR title to reflect that change and avoid squashing the two changes if we keep them in the same PR.

[ivanpauno]

I'm happy if we distribute the event status definitions into their own header files, but I think it would be best done in it's own PR as it seems completely orthogonal to adding a new event type. At the very least, we should update this PR title to reflect that change and avoid squashing the two changes if we keep them in the same PR.

Yes, I'm not planning to squash both commits.
The header redistribution was to avoid increasing the size of (the already big) types.h.
I then added the extra events_statuses folder, to avoid having a lots of headers in a flat layout.

[jacobperron]

LGTM, but I'd like to have at least a second reviewer for changes in rmw (@ros2/team)

[wjwwood]

Yes, I'm not planning to squash both commits.

I'd much prefer you did and have two separate pr's. It makes changelogs and cherry-picking much easier... But that's fine this time.

[ivanpauno]

I'd much prefer you did and have two separate pr's. It makes changelogs and cherry-picking much easier... But that's fine this time.

If I rebase merge, the changelog generation and cherry-picking process will be exactly the same than if I open 2 PRs.
I also do the extra step of editing commit messages and adding a reference to the PR (like is automatically done when squash-merging) when rebase merging. So, it's easy to find the original PR from the commit.

I preferred in this case not splitting the PR, as this feature is already composed by 6 PRs.
I can split it if there's a strong preference for that workflow.

[wjwwood]

If I rebase merge, the changelog generation and cherry-picking process will be exactly the same than if I open 2 PRs. I also do the extra step of editing commit messages and adding a reference to the PR (like is automatically done when squash-merging) when rebase merging. So, it's easy to find the original PR from the commit.

If you're adding the back reference in the commit message then that's ok, that's the main thing that's nice to have in the changelog.

[wjwwood]

I preferred in this case not splitting the PR, as this feature is already composed by 6 PRs.

Yeah, but the file reorganization could have been merged directly I think. This pr could have been based on it, and re-targeted after it was merged. Just say, I'd prefer not to couple things into pull requests in those cases.

[wjwwood]

Again, this is all just for future reference. I think think this pr doesn't need to change.

[ivanpauno]

Last force push edited commit messages without introducing code changes.

[ivanpauno]

• Linux
• Linux-aarch64
• macOS (unrelated failures)
• Windows