fix(avatar): use sha256 and inline the federated avatar lookup (#38843)

- Hash emails with sha256. Gravatar moved to sha256, and both it and
libravatar.org serve the same image for either hash.
- Drop `strk.kbt.io/projects/go/libravatar` for a 46 line inline SRV
lookup. It could not bound or cancel its DNS query and panicked on an
unexpected resolver error. The replacement carries the request context
and a 3s timeout.
- Fix federated avatars querying DNS for every avatar on every render.
`loadAvatarSetting` compared a cache field that was never assigned, so
each call rebuilt the resolver and dropped its cache. That cache is
gone, both settings are read where they are used.
- Migration 348 recreates `email_hash` with a 64 char hash column and a
`hash_type` column, so a later algorithm change can tell old rows apart.
The MD5 rows are unreachable and their `UNIQUE` email index would reject
the SHA256 replacements.
- Fix a re-saved avatar form replacing an uploaded avatar with a random
one.
- Remove the `duoshuo` `GRAVATAR_SOURCE` alias, that service shut down
in 2017.
- Remove dead i18n key.

Fixes: https://github.com/go-gitea/gitea/issues/34284
Fixes: https://github.com/go-gitea/gitea/issues/28110
Docs: https://gitea.com/gitea/docs/pulls/499
Signed-off-by: silverwind <me@silverwind.io>

modelmigration/v28/v348.go

@@ -0,0 +1,24 @@
+// Copyright 2026 The Gitea Authors. All rights reserved.
+// SPDX-License-Identifier: MIT
+
+package v28
+
+import (
+	"context"
+
+	"gitea.dev/modelmigration/base"
+)
+
+func RecreateEmailHashTable(_ context.Context, x base.EngineMigration) error {
+	// the rows are unreachable MD5 hashes and their UNIQUE email index would reject the SHA256 replacements
+	if err := x.DropTables("email_hash"); err != nil {
+		return err
+	}
+
+	type EmailHash struct {
+		Hash     string `xorm:"pk varchar(64)"`
+		Email    string `xorm:"UNIQUE(email_hashtype) NOT NULL"`
+		HashType string `xorm:"UNIQUE(email_hashtype) NOT NULL varchar(16)"`
+	}
+	return x.Sync(new(EmailHash))
+}