ci: add action for releasing new docker image and testing it

[gcroci2]

Commits are too messy to be considered, here I summarized what I did:

• Since the instruction from GitHub for Publishing images to GitHub Packages were generating an image without manifest (that was not actually pullable), I ended up by adapting a workflow from rsd repo, that works well.
• The release.yml file now contains also the publication of an updated docker image on GitHub Packages, that happens only when a new package release is published on PyPI. Both the release number and the latest tags are assigned to the newly published image.
• the test-docker-image.yml file runs tests in the latest deployed image. This workflow gets triggered only when a complete release (PyPI + image on GitHub Packages) succeeds.
• In the CI I now fixed ubuntu to 22.04.

Once this PR is merged, we need to do a new release in order to actually publish a correct version of the image. Then we will need to delete the version I published now, that had only testing purposes. I tested the new workflows during the development of the PR and everything should work as exected, but we will know for sure only when a new package release will be published.

[gcroci2]

• ci: add action for releasing new docker image and testing it #640 👈
• dev

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @gcroci2 and the rest of your teammates on Graphite

[DaniBodor]

It's great to have an automated up-date docker image ready to go at all times. Lots of work has gone into this, but I think it was worth it.

There are a few merge conflicts. I think due to the notebook changes. Hopefully easy to solve.

Few questions:

• I have not tested the new install instructions yet. Are these something I can test already, or only after the workflow has triggered at least once?
• Has the new workflow/changes to existing workflows been tested? If not, is there any way to do so before merging (without having to make a fork and release that on PyPi as well)?

[gcroci2]

• I have not tested the new install instructions yet. Are these something I can test already, or only after the workflow has triggered at least once?

During the development I tested them on this branch (by changing the settings in the yml workflow), but as it is now it can't be directly tested. I plan to do a new release as soon as this PR is merged so we can be sure it all works fine, and worst case I'll open immediately a new issue.

• Has the new workflow/changes to existing workflows been tested? If not, is there any way to do so before merging (without having to make a fork and release that on PyPi as well)?

There is no straightforward way. I'll try now to solve the merge conflicts paying attention, but then we will know for sure only with the first real release will be triggered.