Hard delete a bindle

[itowlson]

One of the key principles of the Bindle architecture is immutability - no bindle can ever be modified or deleted.

This is great until:

1. Somebody creates eight dozen apps with variants of "hello world" as their names, and you run out of demo namespace
2. Somebody stores illegal stuff on your Bindle server

The first is merely vexing, and probably not a major issue on production Bindle servers. The second, however, results in Mickey Mouse and Goofy kicking down the server operator's door at 4am to hand them a writ for possession of 400 slightly different encodings of Frozen II.

It would be good if the server operator, at least, could do something about this. It need not be exposed to ordinary users and would be fine strictly as an admin operation.

We would need to consider whether hard deletion would continue to reserve a spot in the namespace. If it did not, it would create an avenue for someone to spoof a bindle, though this would require admin collusion, and is unlikely to happen to bindles that are actually in legitimate use. If it did, then the "polluted test namespace" would continue to be an issue, albeit a minor annoyance rather than anything serious.

[thomastaylor312]

My one big worry with exposing an endpoint in any way means that it is another attack surface someone can use to do something to a bindle server. It also further complicates our authz roles, which we still haven't even figured out yet. Based on how crates does this (which we took the yanking idea from), they don't have a way to delete it and you do have to reach out to the operator to remove. I don't think would happen often enough to necessitate a separate endpoint or system to delete things

[technosophos]

One thing we are considering is making a bindle-server subcommand to remove a bindle from a local storage. This would work for DMCA takedowns and local fixes, but would not expose the behavior over the REST API. That would at least minimize the blast radius of this.