Moving to produce, but not consume Docker Hub images

[Adrian Cole]

As you've probably noticed, Docker Hub will limit authenticated pulls
to 200 per hour (effectively 100 pulls per hour when multi-arch). This
is not enough to operate zipkin as even one pull request could effect
that, and caching alone won't save us.

Through a long chat with Rag and some independent thinking, the
current plan is to push but never pull Docker Hub images, except
perhaps to ensure there was nothing corrupt after releases.

Put another way, internal test or high-frequency change images would
be prefixed with ghcr.io/ whereas images we give to users or use in
our main docker-compose examples stay as-is

Here are some examples:

openzipkin/zipkin:master will not be published anymore, but
ghcr.io/openzipkin/zipkin:master would, as the change frequency of
every commit would easily exceed 200 per 6hrs when combined across the
org.

Both openzipkin/zipkin:2.22.0 and ghcr.io/openzipkin/zipkin:2.22.0
would be published. This allows downstream users who depend on us to
also not lock their accounts in CI workflows

openzipkin/zipkin-builder would not be published anymore, but
ghcr.io/openzipkin/zipkin-builder would. "zipkin-builder" similar to
our java images, are considered "org internal". By not publishing
these to Docker Hub, we remove the temptation to accidentally lock our
accounts.

Anyway, I hope this note helps, and maybe you have other contexts it
can be useful in also!

Best,
-A

[Adrian Cole]

to follow along, you can wind up from this PR which others will link
to https://github.com/openzipkin/docker-java/pull/33