Do not take lock for shared context in setTempDataOnDisk

[vdimir]

Changelog category (leave one):

• Not for changelog (changelog entry is not required)

Changelog entry (a user-readable short description of the changes that goes to CHANGELOG.md):

• Fix rare potential deadlock, close ThreadSanitizer: lock-order-inversion #47072

Documentation entry for user-facing changes

• Documentation is written (mandatory for new features)

Information about CI checks: https://clickhouse.com/docs/en/development/continuous-integration/

[tavplubix]

What about other functions that use temp_data_on_disk? For example

ClickHouse/src/Interpreters/Context.cpp

Lines 739 to 743 in 714b54b

	/// TODO: remove, use `getTempDataOnDisk`
	VolumePtr Context::getTemporaryVolume() const
	{
	auto lock = getLock();
	if (shared->temp_data_on_disk)

[vdimir]

Oh, we have two different temp_data_on_disk one in shared part of context and one in current 🤔 I'll check why do we need two and when it was introduced. Probably shared is global and in current context is for query execution. Global one is set on server startup

ClickHouse/programs/server/Server.cpp

Lines 1048 to 1060 in ceef48a

	if (!server_settings.tmp_policy.value.empty())
	{
	global_context->setTemporaryStoragePolicy(server_settings.tmp_policy, server_settings.max_temporary_data_on_disk_size);
	}
	else if (!server_settings.temporary_data_in_cache.value.empty())
	{
	global_context->setTemporaryStorageInCache(server_settings.temporary_data_in_cache, server_settings.max_temporary_data_on_disk_size);
	}
	else
	{
	std::string temporary_path = config().getString("tmp_path", path / "tmp/");
	global_context->setTemporaryStoragePath(temporary_path, server_settings.max_temporary_data_on_disk_size);
	}

Anyway, better naming and comments are required, so I'm going to investigate how to make it better and continue this PR

[vdimir]

@tavplubix
I renamed temp_data_on_disk in shared context and added comments.
Also added locks for get/set this variable in shared context (not sure if it's mandatory since it's set once at Server::main), but in other places accessing shared parts of context we do (e.g. Context::setFlagsPath)

[tavplubix]

Does it mean that we cannot access Context while holding storage_policies_mutex?

[vdimir]

Reduced scope of storage_policies_mutex not to overlap with getLock()

[vdimir]

Stateless tests (asan) [4/4] — fail: 1, passed: 1269, skipped: 10 Details

#43946