fix(user): allow unblocking users promoted to admin (#39192) (#39402)

Backport #39192 by @loveulvu

Fixes #39189.

`IsUserBlockedBy` intentionally treats admin users as not blocked, but
`CanUnblockUser` was also using it to determine whether a blocking
relationship exists. If a previously blocked user is later promoted to
admin, the existing `user_blocking` record remains but can no longer be
removed.

This change separates those two concerns by adding `HasBlocking` for
checking the persisted blocking relationship. `CanUnblockUser` uses that
relationship check while `IsUserBlockedBy` keeps its existing admin-user
behavior.

A regression test verifies that an admin is still not considered blocked
while an existing blocking relationship can still be unblocked.

Tests:
- `go test ./models/user ./services/user -count=1`

Co-authored-by: Even <412401474@qq.com>

services/user/block.go

@@ -50,7 +50,7 @@ func CanUnblockUser(ctx context.Context, doer, blocker, blockee *user_model.User
 		return false
 	}
 
-	if !user_model.IsUserBlockedBy(ctx, blockee, blocker.ID) {
+	if !user_model.HasBlocking(ctx, blockee.ID, blocker.ID) {
 		return false
 	}
 

services/user/block_test.go

@@ -62,4 +62,8 @@ func TestCanUnblockUser(t *testing.T) {
 	assert.True(t, CanUnblockUser(t.Context(), user1, user2, user29))
 	assert.True(t, CanUnblockUser(t.Context(), user2, user2, user29))
 	assert.True(t, CanUnblockUser(t.Context(), user1, org17, user28))
+	// Existing block can still be removed after the blockee becomes an admin.
+	user29.IsAdmin = true
+	assert.False(t, user_model.IsUserBlockedBy(t.Context(), user29, user2.ID))
+	assert.True(t, CanUnblockUser(t.Context(), user2, user2, user29))
 }