Improve guidance for making good use of signals.

[Aymeric Augustin]

This is a follow-up to ​https://github.com/django/django/pull/11814 and ​https://groups.google.com/d/msg/django-developers/c5sFZ5BEujI/jVLsfSYBAwAJ.

I have two suggestions to improve the documentation of signals.

1. In ref/signals.txt, for each signal, document the alternatives, which will usually be more robust and maintainable:

• Instead of a model signals, you can override the corresponding method in the model class — unless that model is provided by a library and cannot be swapped
• Instead of request/response signals, you can provide a middleware.
• As far as I can tell, other signals don't have a great alternative. You could replace connection_created by a custom database backend but that's a lot more work.

2. In the introduction of topics/signals.txt, replace the list of signals with a good example. In my opinion, setting_changed is likely the best example: many pluggable apps need it in their test suite.

[Mariusz Felisiak]

Thanks. I wouldn't say that providing good examples and alternatives is "Easy picking" that's why I unchecked this flag.

[Caio Ariede]

​PR

[Jacob Walls]

Author appears ready for another review.

[Sarah Abderemane]

Hi there, I would like to give a try on this ticket, but I'm not sure to understand what I should do with this part :

As far as I can tell, other signals don't have a great alternative. You could replace connection_created by a custom database backend but that's a lot more work.

It's to redirect to the part of the documentation where we define custom database or something else?

[Joseph V Zammit]

Tentative PR is open here: ​​https://github.com/django/django/pull/16221

[Carlton Gibson <carlton.gibson@…>]

In 71e9694:

Fixed #30801 -- Improved guidance for making good use of signals.

[Carlton Gibson <carlton.gibson@…>]

In 018311d:

[4.1.x] Fixed #30801 -- Improved guidance for making good use of signals.

Backport of 71e9694856627d4027c9df066045f0e1c2b5cf27 from main