Docs have incorrect default for HIDE_IN_STACKTRACES

[goblinJoel]

At https://django-debug-toolbar.readthedocs.io/en/latest/configuration.html , the HIDE_IN_STACKTRACES default is stated to be ('socketserver', 'threading', 'wsgiref', 'debug_toolbar', 'django'). The actual default only hides a few Django modules, not all of it.

In 2.0, the actual default is:

    "HIDE_IN_STACKTRACES": (
        "socketserver",
        "threading",
        "wsgiref",
        "debug_toolbar",
        "django.db",
        "django.core.handlers",
        "django.core.servers",
        "django.utils.decorators",
        "django.utils.deprecation",
        "django.utils.functional",
    ),

Edit: I just realized that these are prefixes rather than exact matches, so submodules are also omitted, which is great. Would this be worth documenting?

Related question: Is anyone else having their browser lag and max out a CPU core when looking at the SQL panel with stacktraces enabled? The reason I noticed this doc issue was I wanted to add django.test.utils, django.template.base, and django.template.loader_tags to the hidden modules to see if that fixed my issue. (I get a lot of those in certain SQL stacktraces.)

[matthiask]

Yes, this would be worth documenting; also updating the docs to match the code is a good idea in this case.

Re. CPU: This doesn't seem to happen to me. It's also the first time I'm reading about performance-related problems with the SQL panel -- the templates panel is known to be problematic at times, but the SQL panel, that's news to me.

[goblinJoel]

I've found the SQL panel to be a bigger performance hit than the templates panel for some time, but that's certainly not new to 2.0. Perhaps it's only an issue with larger amounts of queries? Many of our pages have >100, though we've been trying to reduce that. I just updated from DjDT 1.8 to 2.0 and ran into the browser CPU issue (and much larger response sizes); before the update, it just took a few extra seconds server-side to generate the page and returned a somewhat larger response.

I suppose that's an issue for a different issue though.