Add SHA256 git support to Gitea

[dirkmueller]

The current default of SHA1 in distributed per-package gits could be potentially too weak as it allows for collision attacks (collisions are only avoided on a per repo basis). To mitigate that we could start with sha256 gits right away. The alternative would be monorepo, which however many dislike.

Gitea currently is not able to support SHA256. We need to add support.

[dirkmueller]

@AdamMajer has started an implementation upstream: go-gitea/gitea#23894

[AdamMajer]

The caveats here to remember.

On positive side:

• signed sha256 repository commits are probably secure and we don't have to worry about weakening integrity checks via sha1 weaknesses
• native integrity check without external tools like Git-EVTag-v0-SHA512

On negative side

• sha256 repositories can't interact with sha1 repositories, which means using upstream's spec files (ie. native packaging) probably will not work until https://git-scm.com/docs/hash-function-transition/ is implemented
• sha256 support is still listed in git as "experimental"

[JanZerebecki]

While not the best decision security wise, I lean towards stick with the git default of sha1 for now:

• no risk of tripping over something that hinders our move
• no risk of needing to rewrite history if some incompatibility with the existing sha256 implementation happens
• we do not prevent us from adopting workflows that directly combine with upstream repos, which will mostly be sha1 (this seems to be the only heavy reason in favor sticking with sha1)
• we might be able to adapt git-evtag for commits if we need to be compliant before migration is ready
• we need someone to implement the migration in upstream git anyway, without that the risk of sha1 still exists in upstream repos