One singular self._delete_task: remove _num_connections and deprecate prune_instances

[evnchn]

Motivation

TL-DR: If you want something to always get cleaned up, clean it up in one place, never switch PICs. Keep logic clean and firm by always cleaning up when the function elapses - only way to stop it is to cancel the function.

So a client should, ideally, self-destruct.

But now a client is destroyed in a variety of places, and only sometimes it actually destroys.

• Before socket connect: by Client.prune_instances
• After socket connect: by the _delete_tasks, which can be multiple, but we act on the last one because we only actually delete when self._num_connections[document_id] == 0

This is quite some technical debt (no we are not 🤡 enough to write this on day one). Some left from 2.x when we had auto-index client. This PR seeks to eliminate it.

Implementation

Removals and deprecations:

• No more _num_connections.
• No more _delete_tasks (plural).
• Deprecate Client.prune_instances (does nothing now)

Additions

• We do a singular _delete_task. Considering the above, only the last one matter anyways, so why bother.
• self._reset_self_delete: For share the logic between the existing socket-disconnect self-delete, and the before-connect 60-second self-delete

Progress

• I chose a meaningful title that completes the sentence: "If applied, this PR will..."
• The implementation is complete.
  • Pray to pytests
• Pytests are not necessary.
• Documentation is not necessary.
  • Possibly to warn the user if they manually call Client.prune_instances though.

[evnchn]

The force-pushes are due to incomplete pylint fixes.

We can agree that force-push are for "commits you don't want people to see"

[evnchn]

Recap on the two reverts:

8414e1d is a bad idea, since it causes a breaking change.

Rather, 4ada9e4 makes _reset_self_delete tolerant in a manner that we don't need extra config for Client created before the core loop is ready. Added benefit is, if such client persists to a stage where the core loop is ready, then we can take care of deleting the client.

1548190 is a bad idea, since when a client is deleted by something other than the self-destruct mechanism, it will leave behind a delete task which does nothing. Ideally, a deleted client should be as dead as a doorknob.

In f212c5c I cancel the delete task if the client is deleted, so it really is as dead as a doorknob

[falkoschindler]

@evnchn Today I talked to @rodja about PR #5421 (introducing shared pages). Even though we're definitely going to mark them as experimental with a list of known limitations, they might benefit from the current _num_connections dictionary to handle multiple browser tabs with poor connection visiting a single shared page. Therefore I think we should at least put this PR on hold and see if PR #5421 gets released.

[evnchn]

We can still simplify the logic while keeping _num_connections (I think).

But still I don't think it's worth the effort to do that when #5421 is a "maybe". Let's leave it later.