Changelog category (leave one):

• Not for changelog (changelog entry is not required)

Closes #59114

In https://s3.amazonaws.com/clickhouse-test-reports/74014/dcdccd54f13e74c5018f6d40e5a4caa77858dc22/stress_test__debug_.html CurrentThread::getGroup() returned nullptr when called from TCPHandler::processOrdinaryQuery. This means that calls to CurrentThread::attachToGroup/detachFromGroupIfNotDetached are not properly nested: someone detached a thread that they didn't attach. (The thread is expected to be attached to a group because the caller of processOrdinaryQuery holds a QueryScope for the duration of the call.)

Almost all calls to CurrentThread::attachToGroupIfDetached/detachFromGroupIfNotDetached follow this pattern that looks incorrect:

    auto thread_func = [thread_group = CurrentThread::getGroup()]
    {
        SCOPE_EXIT_SAFE(
            if (thread_group)
                CurrentThread::detachFromGroupIfNotDetached();
        );

        if (thread_group)
            CurrentThread::attachToGroupIfDetached(thread_group);

        ...
    };

If the thread is already attached to a group, it'll end up detached after this function returns. Normally such thread_func is immediately scheduled on a thread pool; then the thread shouldn't be already attached to a group (... or so I'm assuming; there were no asserts about this, so CI on this PR may prove this analysis wrong). But some code sites sometimes call such function directly, e.g. Aggregator::prepareBlocksAndFillTwoLevelImpl. AFAICT, this would incorrectly detach the thread from the thread group. I'm guessing this is what caused these test failures (but I didn't try to reproduce this and don't have an explanation for why the crash happens so rarely.)

This PR replaces this pattern with a more correct one, with a bunch of asserts, wrapped in a RAII thing.

Most changes are mechanical. Most substantial ones are in ThreadStatus.h, ThreadStatusExt.cpp, and ProfileEventsExt.cpp.