Introduce self-hosted Gitea & Codeberg API endpoints

[algernon]

This PR has two parts: the first commit introduces the /v1/gitea/:host/:user/:repo/ family of routes, supporting any self-hosted Gitea or Gitea-compatible forge. The second commit introduces /v1/codeberg, a simple redirect to /v1/gitea/codeberg.org,

[algernon]

FWIW, there's a Gitea forge at gitea.com, but it isn't advertised much, as far as I can tell, so I did not make /v1/gitea default to it. That can be arranged later, I suppose, if/when the need arises.

[cafkafk]

The second commit introduces /v1/codeberg, a simple redirect to /v1/gitea/codeberg.org,

I like this approach. I'll try to review this tomorrow after I've gotten some sleep.

[cafkafk]

Codewise, I just have some nitpicks on formatting of log outputs.

---

I tested codeberg on

nix flake show 'http://localhost:3000/v1/codeberg/firefish/firefish.tar.gz' 

(which did have an error, but not on rime's part, so that endpoint seems functional)

I like how we get to use the get_repo_refs endpoint for version, branch, and
tag, very neat (might see if I can get this to work for github).

I couldn't find any gitea instances with nix flakes that had releases. If you
know any we could use to test against that would be useful (specially since I
should probably write some tests sooner or later). Another option might be that
I make a trivial flake repo with a release on codeberg and some self hosted
instance to test against.

Another more general question: codeberg runs on forgejo right, not gitea, and
they seem to be compatible... But I wonder if we should name this endpoint
forgejo, and then have a gitea endpoint redirect to it? If for no other reason
than the fact that forgejo seems the more FOSS adjacent option, and between the
two, I personally lean more towards supporting their project. I wonder how you feel about this?

[algernon]

Codewise, I just have some nitpicks on formatting of log outputs.

Thanks, will correct them a bit and force-push!

I couldn't find any gitea instances with nix flakes that had releases.

https://git.madhouse-project.org/algernon/riemann-c-client - that has a flake on the 2.1.1 release, so nix run 'http://127.0.0.1:3000/v1/gitea/git.madhouse-project.org/algernon/riemann-c-client/v/riemann-c-client-2.1.1.tar.gz' will do the trick (it prints the help output of the CLI tool).

Another more general question: codeberg runs on forgejo right, not gitea, and they seem to be compatible...

They are, indeed. Forgejo is pretty much Codeberg's soft-fork of Gitea, and thus, they are compatible.

But I wonder if we should name this endpoint forgejo, and then have a gitea endpoint redirect to it? If for no other reason than the fact that forgejo seems the more FOSS adjacent option, and between the two, I personally lean more towards supporting their project. I wonder how you feel about this?

I... considered this too, but ultimately, Gitea is the upstream project, so having that as the main endpoint felt more correct, even if Forgejo is more open. I'm happy to rename the endpoint nevertheless, because showing support for the more open variant is also the right thing to do. You know what? I'll do that.

As for the redirect: what if we didn't need a redirect, and would just use the same routes for both /v1/forgejo and /v1/gitea? With Axum, it is possible to nest Routes, so if the giteaforgejo endpoints get changed to /:host/:user/:repo/..., then the v1 route can use .nest("/v1/forgejo", get_forgejo_routes()).nest("/v1/gitea", get_forgejo_routes()), and both will be handled by the same code, without any redirects. If this setup is something you're okay with, I can either include that in this PR, or leave the gitea alias for now, and do it in a separate one. Personally, I'd do it in a separate PR, to not conflate things too much.

[algernon]

Updated the log messages, and renamed the endpoint from gitea to forgejo - new version of the PR force pushed.

[cafkafk]

If this setup is something you're okay with, I can either include that in this PR, or leave the gitea alias for now, and do it in a separate one. Personally, I'd do it in a separate PR, to not conflate things too much.

I think that sounds very cool, and yea, I think it's good to do this in a separate PR.

[cafkafk]

Testing current and added endpoints indicate this is working without regressions, LGTM 👍 merging