Add rosidl_runtime_rs from the ros2-rust repository

[esteve]

This PR moves the rosidl_runtime_rs folder from ros2-rust @ 9a845c17873cbdf49e8017d5f0af6d8f795589cc

[nwn]

I know this was discussed in the working group meeting, but it might be worth recording here the reasoning for why we're splitting rosidl_runtime_rs into a separate repo from the generator in rosidl_rust. I believe we chose to model this after how it's done for Python with the rosidl_python/rosidl_runtime_py split, rather than how it's done for C++, where everything is in rosidl. However, I don't recall the reasoning behind that.

[maspe36]

LGTM, but yeah good question @nwn. Do we really gain anything by having the generator and the runtime being separate repos? Do we ever actually want to version these separately?

[mxgrey]

Do we really gain anything by having the generator and the runtime being separate repos?

Yes, the first thing to be aware of is that the ROS buildfarm currently requires all packages within the same repo to have the same version number. I can't speak to the reason for that requirement, but I've been told it's baked in right now and inviolable.

The next thing to be aware of is that any time a version gets bumped for any package on the buildfarm, it will have to rebuild all packages that (transitively) depend on the one whose version was bumped.

Our goal is for rosidl_generator_rs to become a default IDL generator, which means all message packages on the buildfarm will depend on it. Any version bump on rosidl_generator_rs will force a version bump for all message packages.

In contrast, rosidl_runtime_rs will only be a dependency for rclrs and any nodes built with rclrs. That's a much smaller pool of dependencies than rosidl_generator_rs will have.

By keeping them in separate repos, we can make changes to rosidl_runtime_rs and as long as those changes are compatible with the current version of rosidl_generator_rs, we will not need to trigger a rebuild for all message packages on the buildfarm.

[mxgrey]

Retaining all the commits is really great. The loss of timestamps is unfortunate, but at least we can see the order of all the commits, so we can still retrace how the implementation evolved over time.

Very clean migration 👍

[esteve]

@maspe36 @nwn @mxgrey thanks for your reviews. I gave it another try and I've managed to keep the timestamp thanks to this answer on Stackoverflow:

https://stackoverflow.com/a/5520650

For future reference the command I used was:

$ git filter-branch --commit-filter 'export GIT_COMMITTER_NAME="$GIT_AUTHOR_NAME"; export GIT_COMMITTER_EMAIL="$GIT_AUTHOR_EMAIL"; export GIT_COMMITTER_DATE="$GIT_AUTHOR_DATE"; git commit-tree "$@"' -- origin/main..HEAD

I was also able to keep the original author for each commit without adding myself as a committer.

[esteve]

Ugh, turns out that when merging this onto main, GitHub decided to do a rebase and undo the timestamp trick, now all the commits have the current timestamp. I'll do a force push onto main to correct that.