Update legacy version as it's not compatible after setuptools 66+

[marcoag]

It seems that legacy versions are not supported after setuptools 66+: pypa/setuptools#2497.

This results in the the following error:

setuptools.extern.packaging.version.InvalidVersion: Invalid version: '3.0.1-master'

I updated the version so it works, not sure if this is the correct one we want to set so feel free to suggest a different one.

[nuclearsandwich]

This is probably the correct thing to do, but this version syntax has been in use by the production buildfarm for quite some time and changing it may require deeper review and changes.

[cottsay]

I've been using this and it seems to work correctly. I'll hold off merging until @nuclearsandwich has conducted or clarified the aforementioned testing.

[nuclearsandwich]

This is probably the correct thing to do, but this version syntax has been in use by the production buildfarm for quite some time and changing it may require deeper review and changes.

Thanks for holding off on this based on my concerns. To satisfy myself I had to re-read many o of the job configuration templates and how they track the package version, because I had rough memories of dealing with ros_buildfarm changes when doing the xenial branch migration.

When running configurations locally, the current git branch is found and used via git-rev-parse so reaching the codepath that this changes locally required some experimentation.

That the master branch is also used as a default value in the job templates also made it hard to observe detection failures when working with a local master branch incorporating these changes.

Looking at the Version API in https://packaging.pypa.io/en/stable/version.html it looks like we're now using a "local version" specifier. I'm not sure how that compares to the Legacy API but it seems reasonable.

When this started hitting me on Archlinux I began using a development release specifier rather than the local specifier: 3.0.1.dev0 Since we do frequently work from this main branch does it make sense to indicate that what's in production is always a development release rather than a true release as well? If so I can add that in a follow-up PR.