Workflow [PR], commit [9e43064]

Summary: ❌

Couple of TODOs.

1. Need to restrict background profile from potentially used to connect to server. The following draft works preliminarily, I'm assessing whether it's enough or something else is needed:

void Context::setUser(const UUID & user_id_, const std::vector<UUID> & external_roles_)
{
    /// Prepare lists of user's profiles, constraints, settings, roles.
    /// NOTE: AccessControl::read<User>() and other AccessControl's functions may require some IO work,
    /// so Context::getLocalLock() and Context::getGlobalLock() must be unlocked while we're doing this.

    auto & access_control = getAccessControl();
    auto user = access_control.read<User>(user_id_);

    auto default_roles = user->granted_roles.findGranted(user->default_roles);
    auto enabled_roles = access_control.getEnabledRolesInfo(default_roles, {});
    auto enabled_profiles = access_control.getEnabledSettingsInfo(user_id_, user->settings, enabled_roles->enabled_roles, enabled_roles->settings_from_enabled_roles);

+    std::unordered_set<String> system_profiles = {
+        getGlobalContextInstance()->shared->system_profile_name,
+        getGlobalContextInstance()->shared->background_profile_name,
+        getGlobalContextInstance()->shared->buffer_profile_name
+    };
+
+    for (const auto & [profile_id, profile_name] : enabled_profiles->names_of_profiles)
+    {
+         if (system_profiles.contains(profile_name))
+         {
+            throw Exception(
+                ErrorCodes::ACCESS_DENIED,
+                "Profile '{}' is a system profile and cannot be used for user connections.",
+                profile_name);
+         }
+    }

2. There was a kinda similar change - Don't propagate user settings for background ops #64456 - which potentially becomes rudimentary with this change. I'm assessing whether this should be addressed within the same PR or not:

Context::isBackgroundOperationContext()
Context::setBackgroundOperationTypeForContext()

All committers have signed the CLA.

Couple of TODOs.

1. Need to restrict background profile from potentially used to connect to server. The following draft works preliminarily, I'm assessing whether it's enough or something else is needed:

The settings are given in the profile 'background'. Connectivity using such profile is possible by explicitly setting up a user. So restriction is not necessary.

2. There was a kinda similar change - Don't propagate user settings for background ops #64456 - which potentially becomes rudimentary with this change. I'm assessing whether this should be addressed within the same PR or not:

done

Failures of Integration tests (amd_asan, targeted), specifically 'test_ttl_move' and its friends, is another flavour of #85011.

What happens is:

• first this test failed due to natural reasons at early implementation which was completely broken
• then this test became a part of 'targeted' suite as suspicious, and it got hammered at each execution thoroughly, which exposed the original issue with it
• the hypothesis is that the timings shift under the pressure at 'targeted' execution, and fire more often

For this PR we assume it as flaky and ignore it. To prove that I drafted #94853 with exactly same code, but in a clean state - those tests do not fail there.

As for further actions, I self-assigned to #85011 and modified my draft #94853 to actually fix the flaky test.

BTW I think would be convenient to later add something like this for background streaming operations (like s3queue, kafka, etc).