Deleting crates deletes reverse dependencies

[Turbo87]

If a crate is deleted again with the first 72 hours, and if it already has reverse dependencies (i.e. another crate has a dependency on it), then these reverse dependencies are currently automatically deleted from the database (and the index) due to the corresponding foreign key constraints.

see https://rust-lang.zulipchat.com/#narrow/channel/318791-t-crates-io/topic/crate.20deletion.20interactions.20with.20the.20index

There are a couple of options how we can handle this:

• do nothing and keep everything as-is
  • the cargo team indicated that cargo does not expect dependency declarations of existing versions in the index to change and throws errors when this happens
• change the crate deletion rules to require zero reverse dependencies also within the first 72 hours
  • if an author publishes crate A and a new version of existing crate B that uses crate A, then the author has no way to ever delete crate A again since version deletions were never implemented and removed from the crate deletions RFC
• in addition to the dependencies.crate_id column we can have a dependencies.crate_name column with the former being set to NULL if the corresponding crate is deleted
  • this would allow us to keep the dependency declarations in the database and index alive, but pointing at nothing
  • ... or pointing to another crate that was later published with the same name
  • this seems to match what npm is doing
  • the dependencies table is already one of our largest tables. adding a mostly redundant text column might increase the size quite a bit and could affect query performance. it might be possible to only fill the column once the crate is actually deleted though.

[Eh2406]

Seems like we are on option 2 at the moment. So the paths forward are:
A - Stay on option 2 indefinitely
B - Stay on option 2, until we have carefully designed and implemented option 3.

I don't see any time pressure to design option 3. So lets YAGNI until we have clear justification of why option 3 needs to be done soon.

[ehuss]

With regards to the proposed solutions, at this time the Cargo team would prefer that crates.io disallow all user deletions when there are reverse dependencies (option 2). This is a simple solution that helps reinforce the technical and cultural expectation that changes in dependencies cannot break a user's application.

For when deletion is necessary, if all dependents are within the deletion policy, the user can delete them first to remove the reverse dependencies that are blocking their deletion. In extenuating circumstances, administrative action can still be taken to delete a crate. We should probably coordinate on a policy on how administrative deletions are performed but we assume those are rarer and so it's a lower priority to solve that problem.

[LawnGnome]

We discussed this at our team meeting today, and agreed that we'll go with option 2 — namely, preventing crates with reverse dependencies from being deleted. Thanks to the Cargo team for the feedback! (And especially to @Rustin170506 for helping to facilitate.)

So I'll update #10591 to not have the wording about this being temporary any more, and that should close this out.