Draft: Validate presence of Organization on Namespace model

What does this MR do and why?

This MR introduces a validation for presence of Organization on the Namespace model. This is an important step for the Cell project, since we want a lot of data to be scoped to one Cell. For Namespaces, the organization_id will be the sharding key

Adding this validation is a complex and impactful change. And a lot of specs and code will change. If we would introduce this validation in MR, there would many more changes. So we need a way of reducing the number of changes and we can do that by disabling the the validation initially and then follow-up with a few MR's that enable the validation

In this MR:

• Adding the actual validation (and corresponding specs)
• Adding a way of disabling the validation
• Changes in specs that are unavoidable

This MR has a lot of changes. But 26 changes are disabling the validation.

Validation disabled

The validation is dependent on the setting of Gitlab::SafeRequestStore[:require_organization]

Namespace.with_disabled_organization_validation do
	Groups::CreateService.new(current_user, group_params).execute
end

This will:

• Set Gitlab::SafeRequestStore[:require_organization] to false
• Run the code, skipping the validation
• Set Gitlab::SafeRequestStore[:require_organization] to true

For specs, the Gitlab::SafeRequestStore is disabled. Therefore, we needed to enable it using :request_store modifier. All the specs in spec/support/helpers/disable_namespace_organization_validation.yml are executed with Gitlab::SafeRequestStore enabled.

Next steps

There will be a few followup MR's.

The way of working would be:

• Remove locally a Namespace.with_disabled_organization_validation usage
• Update specs and test the changes
• Remove specs from the spec/support/helpers/disable_namespace_organization_validation.yml if the disablement is no longer needed

MR acceptance checklist

Please evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Screenshots or screen recordings

Screenshots are required for UI changes, and strongly recommended for all other merge requests.

Before	After

How to set up and validate locally

Numbered steps to set up and validate the change are strongly suggested.

Related to #411832