Implement publish notifications opt-out

[Turbo87]

It looks like some people are rather unhappy about the new publish notifications introduced in #9341 (see https://rust-lang.zulipchat.com/#narrow/stream/318791-t-crates-io/topic/publish.20notification.20emails/near/465824072 and #9355).

This PR adds a per-user settings flag to opt-out of these notifications:

This PR is best reviewed commit by commit 😉

Resolves #9355

[codecov]

Codecov Report

Attention: Patch coverage is 97.72727% with 3 lines in your changes missing coverage. Please review.

Project coverage is 89.09%. Comparing base (cdb554c) to head (fc92785).
Report is 37 commits behind head on main.

Files with missing lines	Patch %	Lines
src/controllers/user/update.rs	95.16%	3 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #9359      +/-   ##
==========================================
+ Coverage   89.06%   89.09%   +0.03%     
==========================================
  Files         285      286       +1     
  Lines       28938    29032      +94     
==========================================
+ Hits        25773    25867      +94     
  Misses       3165     3165              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[epage]

I assume the email should be updated with an "Unsubscribe" link to make sure people are aware of this.

In general, I think enabled-by-default will make security worse, not better. First, the concern over the lack of an opt-out was raised about a year ago. In that discussion, I called out the security risks of spamming people with this. Even when "unsubscribe" links are provided, it seems users are more inclined to click the "spam" button than to unsubscribe. Email providers seem to cross-pollinate that information between accounts and start treating it as spam even if you never said it was. This means one user not wanting email notifications can effectively opt-out other users from getting these emails! A user who wants the emails is trusting in the system to receive them and think everything is ok because they haven't received one. It can be easy to overlook the lack of emails being sent when you do your own publishes, if you are in that scenario.

[Eh2406]

Without diminishing the pain this is causing. Why has this been such a large issue in our community when many other ecosystems do not provide an opt out? pypi, npn, and others do not have an opt out. what is different about the implementation or the community to cause the disparate impact?

A user who wants the emails is trusting in the system to receive them and think everything is ok because they haven't received one.

A non-distributed version of this problem is also a problem if we provide an opt out. An attacker can opt out then publish then opt back in so that the website still says your opted in but you never got the email for the publish.

[epage]

pypi, npn, and others do not have an opt out. what is different about the implementation or the community to cause the disparate impact?

As I brought up on zulip, I have no idea what policy PyPI uses but I've never received a notification for a publish to PyPI. I am a sole owner on a couple of packages and published one this morning.

We also shouldn't blindly copy from other ecosystems but see what lessons we can learn from them and adapt accordingly.

[pietroalbini]

Without diminishing the pain this is causing. Why has this been such a large issue in our community when many other ecosystems do not provide an opt out? pypi, npn, and others do not have an opt out. what is different about the implementation or the community to cause the disparate impact?

At least what makes me really want this feature is the "owner accounts" pattern that is popular in crates from large organizations. For example, I receive notifications from @rust-lang-owner, and that means every monday I get ~35 emails about rust-analyzer being published, or ~10 emails when cargo gets published after a new release, and random emails whenever a CI workflow somewhere in the rust-lang org publishes a crate.

Those emails are pure noise, because I am not involved in any way about those crate publishes, and I can't verify whether those were intentional or not.

A non-distributed version of this problem is also a problem if we provide an opt out. An attacker can opt out then publish then opt back in so that the website still says your opted in but you never got the email for the publish.

We can have the website send an email whenever notifications are disabled and enabled, to ensure there are at least some mails receive. We can make that "notifications disabled" email as scary as it needs to be.

[Turbo87]

@rust-lang/crates-io this still needs a review... 😉

[eth3lbert]

I've left some minor feedback.

This implementation focuses on user-level settings. I'm unsure if anyone needs more granular settings like crate-level settings, but for now, this LGTM 👍