Better publisher validation email PublisherService.cs

[hariedo]

Potential alternative to Issue 58
#58

We have a lot of existing @publishers with no database to associate them with the packageID they published.

Instead of relying on a database of publisher/package IDs, we offer an improved publisher validation email that explains how a real publisher can fight back against spam (if it's happening).

[github-actions]

🚀 Deploy this PR to an environment

You can deploy this PR to either development or staging environment:

• Comment /deploy_dev to deploy to the development environment

Alternatively, you can:

1. Go to Actions tab
2. Click on "Manual Deploy to Firebase" workflow
3. Click the "Run workflow" button
4. Select branch: hariedo-publisher-email-1
5. Choose environment: DEV
6. Enter a deployment message
7. Click "Run workflow"

[deepsource-io]

Here's the code health analysis summary for commits e1653fb..5821e97. View details on DeepSource ↗.

Analysis Summary

Analyzer	Status	Summary	Link
C#	✅ Success	❗ 1 occurence introduced	View Check ↗

---

💡 If you’re a repository administrator, you can configure the quality gates from the settings.

[SimplyJpk]

It has never been a problem, just one of those things where it could have become a problem from a malicious user. I think your change is practical, at least gives a user more of an option.

I think it might be a good idea to have a loose restriction per userid/pubid and have a runtime list/dictionary of ids for last time requested, number of times requested and publisher id since we'd have a quick way to confirm activity of the command. (Something similar to the welcome channel protection basically) But that can be added later if we ever have a problem with these emails.

[hariedo]

/deploy_dev

[github-actions]

🚀 Starting deployment of Unity-Developer-Community/UDC-Bot:hariedo-publisher-email-1 to development...