**Describe what's wrong**

Wrong table name in logs after table `RENAME`


**Does it reproduce on recent release?**

Yes.
**How to reproduce**
22.6

```
CREATE TABLE table_test_a
(
    `key` UInt32
)
ENGINE = MergeTree
ORDER BY key;

INSERT INTO table_test_a SELECT *
FROM numbers(1000);

RENAME TABLE table_test_a TO table_test_b;

SELECT *
FROM table_test_b
FORMAT `Null`;


[LAPTOP-] 2022.06.13 10:58:18.370192 [ 27745 ] {43b0dc5d-69e6-4e42-b96c-a13871b6a791} <Debug> executeQuery: (from 127.0.0.1:58484) SELECT * FROM table_test_b FORMAT Null; (stage: Complete)
[LAPTOP-] 2022.06.13 10:58:18.370599 [ 27745 ] {43b0dc5d-69e6-4e42-b96c-a13871b6a791} <Trace> ContextAccess (default): Access granted: SELECT(key) ON test.table_test_b
[LAPTOP-] 2022.06.13 10:58:18.370665 [ 27745 ] {43b0dc5d-69e6-4e42-b96c-a13871b6a791} <Trace> ContextAccess (default): Access granted: SELECT(key) ON test.table_test_b
[LAPTOP-] 2022.06.13 10:58:18.370714 [ 27745 ] {43b0dc5d-69e6-4e42-b96c-a13871b6a791} <Trace> InterpreterSelectQuery: FetchColumns -> Complete
[LAPTOP-] 2022.06.13 10:58:18.370783 [ 27745 ] {43b0dc5d-69e6-4e42-b96c-a13871b6a791} <Debug> test.table_test_a (SelectExecutor): Key condition: unknown
[LAPTOP-] 2022.06.13 10:58:18.370817 [ 27745 ] {43b0dc5d-69e6-4e42-b96c-a13871b6a791} <Debug> test.table_test_a (SelectExecutor): Selected 1/1 parts by partition key, 1 parts by primary key, 1/1 marks by primary key, 1 marks to read from 1 ranges
[LAPTOP-] 2022.06.13 10:58:18.370847 [ 27745 ] {43b0dc5d-69e6-4e42-b96c-a13871b6a791} <Trace> MergeTreeInOrderSelectProcessor: Reading 1 ranges in order from part all_1_1_0, approx. 1000 rows starting from 0
[LAPTOP-] 2022.06.13 10:58:18.371812 [ 27745 ] {43b0dc5d-69e6-4e42-b96c-a13871b6a791} <Information> executeQuery: Read 1000 rows, 3.91 KiB in 0.0015354 sec., 651296 rows/sec., 2.48 MiB/sec.
[LAPTOP-] 2022.06.13 10:58:18.371956 [ 27745 ] {43b0dc5d-69e6-4e42-b96c-a13871b6a791} <Debug> MemoryTracker: Peak memory usage (for query): 45.10 KiB.
```
**Expected behavior**

Correct table name in logs


**Additional context**

Interesting, does it affect grants and etc (looks like no, in ContextAccess log it's using correct table name )

{
        if (!part_info.valid_name || part_info.prefix.empty())
            continue;
        const auto & removable_detached_parts_prefixes = DetachedPartInfo::DETACHED_REASONS_REMOVABLE_BY_TIMEOUT;
        bool can_be_removed_by_timeout = std::find(
            removable_detached_parts_prefixes.begin(),
            removable_detached_parts_prefixes.end(),
            part_info.prefix) != removable_detached_parts_prefixes.end();
        if (!can_be_removed_by_timeout)
            continue;
        time_t current_time = time(nullptr);
        ssize_t threshold = current_time - getSettings()->merge_tree_clear_old_broken_detached_parts_ttl_timeout_seconds;
        auto path = fs::path(relative_data_path) / "detached" / part_info.dir_name;
        time_t last_change_time = part_info.disk->getLastChanged(path);
        time_t last_modification_time = part_info.disk->getLastModified(path).epochTime();
        time_t last_touch_time = std::max(last_change_time, last_modification_time);
        if (last_touch_time == 0 || last_touch_time >= threshold)
            continue;
        renamed_parts.addPart(part_info.dir_name, "deleting_" + part_info.dir_name, part_info.disk);
    }
    LOG_INFO(log, "Will clean up {} detached parts", renamed_parts.old_and_new_names.size());
    renamed_parts.tryRenameAll();
    for (const auto & [old_name, new_name, disk] : renamed_parts.old_and_new_names)
    {
        removeDetachedPart(disk, fs::path(relative_data_path) / "detached" / new_name / "", old_name, false);
        LOG_DEBUG(log, "Removed broken detached part {} due to a timeout for broken detached parts", old_name);
    }
    return renamed_parts.old_and_new_names.size();
}
size_t MergeTreeData::clearOldWriteAheadLogs()