Issue title: Proposal: Add "lock" or "no delete" flag to container
 Issue body: Sometimes you have really important containers, like data only containers, that you don't want accidentally deleted.  `docker rm -f $(docker ps -qa)` is just too easy to type sometimes and then, "oh !@#!", it's all gone.  (Well not really because you can find your data in `/var/lib/docker/vfs`).  Anyhow, I propose we add the following:

`docker run/create --lock=true ...`
`docker lock CID`
`docker unlock CID`

If one was to do `docker rm CID` and CID was locked it wouldn't delete and exit with an error code.  Start/stop/restart should still work.  This flag is the equivalent of EC2's `DisableApiTermination` flag.  In order to delete a locked container you must first run `docker unlock CID`.
 Comments: 
 Comment 0: A PR for this was created some time ago, but voted against by Solomon; https://github.com/docker/docker/pull/7523#issuecomment-59592874 not sure if he's still against it?
 Comment 1: Thanks @thaJeztah, you're an encyclopedia of Docker PRs.
 Comment 2: @shykes You already said no to this in https://github.com/docker/docker/pull/7523#issuecomment-59592874, but I'd like you to reconsider.  We could use a special label for this, but just as you said you don't like "pin" as it seem very specific, along the some lines, I don't really like magic label names.  Labels should really be used for things above/outside of Docker engine.

I usually look at AWS for a good litmus test as whether a specific piece of API functionality is a good idea.  While AWS isn't perfect, they have a very good track records of making extremely thoughtful changes to their API.  EC2 has this similar concept with DisableApiTermination but I think we can make this a bit more generic with "lock".  With "lock" meta data of any kind (nothing is really all that changeable at the moment) should not be modifiable.  This is really no different than when you do `chmod 400` on a file.  As the owner, you could change the file, but you want to put a little bit of a safety net around modifications.
 Comment 3: This is definitely a big one for clean up. There is otherwise no way to do clean up operations when you are running multiple things on the same host and too much cruft builds up quickly when continuously deploying things. 
 Comment 4: +1
 Comment 5: +1
 Comment 6: This would be *really* nice for swarm clusters so that users/operators don't accidentally delete the `swarm` daemons.
 Comment 7: :+1: @rgbkrk 
 Comment 8: :+1: 

This is something that's necessary to avoid the dreaded [Fat Finger Error](https://en.wikipedia.org/wiki/Fat-finger_error).
 Comment 9: +1
 Comment 10: *USER POLL*

*The best way to get notified when there are changes in this discussion is by clicking the Subscribe button in the top right.*

The people listed below have appreciated your meaningfull discussion with a random +1:

@cecitorres
@flaccid
@alanfung
 Comment 11: Definitely a way to protect volumes from deletion is a feature that I personally need before using volumes to host production data. Otherwise the risk of accidentally deleting them while removing a container is too high.

TLDR: :+1:
 Comment 12: @nivox Deleting a container does not delete its volumes unless you do so explicitly `docker rm -v`.
 Comment 13: @cpuguy83 I'm aware of that, but when you have a production servers with tens of container, some of which have unimportant volumes associated with them while others have volumes hosting production data, using the `-v` flag on the wrong container is not an unthinkable occurrence.

Furthermore the current  approach doesn't work all that well in case you have a Dockerfile extending a third party image defining a bunch of volumes that, for whatever reason, you don't really care about. In your Dockerfile however you define a volume that will hold production data.

You create a container off of the image you obtain ending up with:

- *baseVolume1, ..., baseVolumeN*: you might not care about them
- *dataVolume*: you REALLY want this NOT to be deleted

Now when it's time to update the container (new image version), you would like to cleanup all the *baseVolume* while keeping *dataVolume*. Right now you have to manually delete volumes (i.e. `docker volume rm baseVolume`) and then remove the container without the `-v` flag.

An explicit way of marking a volume as protected (i.e. `docker volume pin <volume-id>`) would prevent accidental deletion due to distraction (i.e. `docker rm -v <wrong-container>`) as well as making life easier in cleaning up unimportant volumes.
 Comment 14: +1
 Comment 15: Where are we now with this proposal?

I'm also in favour of having a lock mechanism, despite this seems controversial. I disagree with the fact that further level of classification (multiple security levels) might be required, since removal is a binary operation (possible/not possible).

Another permission-managed operation could be `read` vs. `write` but I'm not sure it makes sense regarding docker, so for now the `deletable` seems to do the trick.
 Comment 16: Yes, I [support a more explicit lock mechanism](https://github.com/docker/docker/issues/17907#issuecomment-163703811). However, an implicit mechanism was added in #19568 so that `--rm` will not remove named volumes. A [note was added to the docs to explain](https://github.com/docker/docker/blob/master/docs/reference/run.md#clean-up---rm), but it's still a confusing/surprising and sometimes dastardly behavior to have volumes (even inherited ones) destroyed unexpectedly.

As a result, newcomers to docker must understand more of the counterintuitive intricacies of docker volumes and docker data containers. From what I've seen, this behavior may have been part of the reason for the rise of data containers -- an additional abstraction around volumes -- when volumes with an explicit lock would have been sufficient. 

tl;dr: use names for your volumes.
 Comment 17: LOL, got a email notification about somebody talking about "locking" containers and was like, "I'm totally going to plus 1 that issues/PR."  Come to find out, it's mine from 2 years ago :(
 Comment 18: Following this discussion, and others (w.r.t. `docker system prune`), perhaps it should be looked at in a wider scope; being able to lock other objects (volumes, networks, secrets, containers, images)
 Comment 19: test
 Comment 20: :+1: 
 Comment 21: +1, this is a major problem with using `docker system prune` to clean up. It removes any volumes not attached to a container, so if for some reason your container happens to have stopped when you prune, your data is gone. I've already lost data to this more than once. A feature to mark volumes as important, so they aren't removed during normal cleanup, would solve this problem.
 Comment 22: @ryannoblett `docker system prune` will no longer automatically prune volumes (you have to specify it with a flag). You can also provide filters to the prune command. You can specify a default set of filters in your CLI config.

Not a 100% perfect solution, but should be ok for most scenarios.
 Comment 23: +1 I use Docker for development purposes in my computer and I do a lot of testing (a hell lot of testing) with containers. BUT I keep a few untouched, like databases and libraries. Sometimes I do some cleaning but it's a PITA to cherry pick the ones that should not be touched. This feature would really save some time among dev teams.
 Comment 24: +1 I use Docker for development purposes in my computer and I do a lot of testing (a hell lot of testing) with containers. BUT I keep a few untouched, like databases and libraries. Sometimes I do some cleaning but it's a PITA to cherry pick the ones that should not be touched. This feature would really save some time among dev teams.
 Comment 25: @pepBR 

> You can also provide filters to the prune command. You can specify a default set of filters in your CLI config.
 Comment 26: @cpuguy83 Couldn't find an example of how to prevent deleting containers using prune filters and using CLI config. Can you point me to the right direction?
 Comment 27: `docker container prune --filter label!=foo=bar` -- This would filter out containers that have a label where `foo=bar`
You can also do `label!=foo` (no value) and it would filter out any container that has a `foo` label regardless of the value.

You can also add this to your `~/.docker/config.json`
```
{
  "pruneFilters": ["label!=foo"]
}
```
 Comment 28: The filter is a little non-intuitive unfortunately, but at least it works.
 Comment 29: @cpuguy83 is there a way to test run without removing stuff? If i use label!=container_id=123456abc, would that preserve one container? It's not carlos01@example.net... and there's no easy to find examples out there.
 Comment 30: @pepBR 
>  is there a way to test run without removing stuff?

No, there was a contributor working on a dry-run mode, however I think they had to work on other things.

>  If i use label!=container_id=123456abc, would that preserve one container?
If you set a container that has a label `container_id=123456abc`, then yes, it would skip over that container.

>  It's not intuitive at all
Yeah, it's a bit weird... I think the issue is the `--filter` nomenclature where it's really more of a "include only" rather than "filter out"

 Comment 31: @cpuguy83 I believe I understand about the label stuff now. But apparently you have to set this inside the Dockerfile, right?

What I would like to do is mark containers by ID. The real important ones here don't have a Dockerfile, I use them directly from the hub.

Thanks a lot for your patience.
 Comment 32: you can set the labels on `docker run`; also, the prune commands don't delete running containers, so you don't have to worry about those.

If you still need finer-grained filtering, it's still possible to combine `docker ps --filter` with `docker rm`
 Comment 33: @thaJeztah Thank you. I'll play a bit inside a VM to better understand how to get what I want. Thank you too @cpuguy83 .
 Comment 34: Oh it's 2022 and i need this too!
 Comment 35: Solution is 3.6 not great, not terrible.
![image](https://user-images.githubusercontent.com/449189/183260514-1325336f-3362-4e55-aade-f77524e23417.png)

 Comment 36: People mighty be interested to know, we merged this to main: https://github.com/moby/moby/pull/44216
New volumes that were created as "anonymous" volumes (e.g. `docker volume create` with no `--name`) are labeled as such, and `docker volume prune` only  considers those volumes for pruning by default.

Unfortunately no solution for volumes created *before* that PR, which will not have the "anonymous" label applied.
{'source': 'GithubIssues', 'repo_name_with_owner': 'docker/docker', 'issue_id': 53274681, 'repo_stars': 31050.0}