Draft: Make cascaded setting lookup for projects more effiicent

What does this MR do and why?

While reviewing !204464 (merged), I tried to understand the reason why we update child record when a parent is updated.

The cascading settings work like this:

• Use setting from NamespaceSetting or ProjectSetting
• If not found, look up setting in the Group hiearchy
• If not found, look up in Application Setting

The above mentioned MR (and also earlier iterations) are changing this to:

• If ApplicationSetting record is updated, update all child records

This is implemented using a Worker that will run a batched 'update_all' on the project_settings and namespace_settings table.

The motivation for this change is

• Database: An N+1 problem (lookup ID's of Group Hierarchy)
• UX: It is not clear for an Admin if a value is inherited or not (?)

Alternative:

This MR explorers an alternative:

• Resolve the N+1 problem by using 1 query for the hierarchy lookup

Advantages:

• No more mass updating of database project/group setting records (which may be a problem with Cells?)
• Remove risk of (accidentally) updating ALL gitlab.com groups & projects settings
• UX: a setting can have two states. When we render Group or Project settings, we can indicate:
  • if setting is empty (NULL, nil): the setting is inherited
  • if setting is defined: the setting is defined on the Group or Project level

Specs pass for ee/spec/models/ee/project_setting_spec.rb spec/models/project_setting_spec.rb

Further iteration

There is also the 'locked' functionality. This means that, if a setting is marked as 'locked', any overrides on child objects are ignored. This needs another query but I suspect that we can integrate this in the 'lookup value in hierarchy' SQL query

Queries

Master branch

• Query for the hierarchy lookup: Simple Namespace by ID lookup
• Query for actual settings: query

This branch

• 1 query: query

References

Screenshots or screen recordings

Before	After

How to set up and validate locally

MR acceptance checklist

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