GeezerVison

I don't really see the point, this does not change the fact that building our docker images depend on the external key servers.

@aduh95 my thinking is, that pulling from the keyring rather than scrapping the Markdown is a better approach. It also moves from a repo that can be changed by any collaborator to one owned by the releasers.
My future thought is that once this script depends on keyring, a CI job on the release-keys repo could trigger the scipt.
As I type out this response though, I'm now thinking that the better approach might be just to pull the recent automation over to the release-keys repo entirely, and just leave the keys/node.keys file here

I'm -1 on touching the node.keys if we can avoid it, as I said in #2459 (comment), it's relied upon by other repos. Also there's value is having it in this repo, if we have to pull the list from somewhere else, it would be hard not to get to a situation where generating the Dockerfiles is no longer reproducible.

There might have been some miscommunication at some point, because tbh none of this effort removes any pain points (at least that I'm aware of), so hum, if ain't broke, don't fix it?
The pain point we have is that the Dockerfiles themselves depend on external key servers we do not control, which means building the docker images is not reproducible as soon as those servers make a change. Last time, it was because I uploaded a new key which overwrote my previous key, which broke the docker images for all versions I had previously signed. A solution for that is #2415, and I'd be relieved if that effort could gain some traction, or at least focus on finding a solution, as it's a bit frustrating that we accept that far-from-ideal current situation.

@aduh95 this doesn't change/remove the node.keys like the other PR does, just uses the keyring as the source of truth