Traversal ids queries

What does this MR do?

Closes #230456 (closed)

Currently to query the namespace hierarchy we must use recursive methods through Gitlab::ObjectHierarchy. We can query the namespace hierarchy a lot faster and easier if we store the path from the root ancestor to each namespace as an attribute on the namespace. We will store this on a new traversal_id attribute on Namespaces.

Say we have this Namespace hierarchy...

graph TD;
    gitlab-->backend;
    backend-->create;
    backend-->manage;
    create-->source;
    manage-->access;
    gitlab-->frontend;

Then the path from gitlab to access is gitlab / backend / manage / access. The path from gitlab to source is gitlab / backend / create / source.

We can use this structure for fast queries. If the current namespace is backend then all our descendants match the path gitlab / backend / *, all our ancestors match the path * / backend, and everyone in the same Namespace hierarchy matches gitlab / *.

We store that path using an array of Namespace ids in a new column on Namespace called traversal_ids.

The recursive Namespace query methods have been moved to a module at app/models/concerns/namespace/recursive_traversal.rb. Feature flags have been included to toggle between using recursive and linear querying methods.

Screenshots

Does this MR meet the acceptance criteria?

Conformity

• Changelog entry
• Documentation (if required)
• Code review guidelines
• Merge request performance guidelines
• Style guides
• Database guides
• Separation of EE specific content

Availability and Testing

• Review and add/update tests for this feature/bug. Consider all test levels. See the Test Planning Process.
• Tested in all supported browsers
• Informed Infrastructure department of a default or new setting change, if applicable per definition of done

Security

If this MR contains changes to processing or storing of credentials or tokens, authorization and authentication methods and other items described in the security review guidelines:

• Label as security and @ mention @gitlab-com/gl-security/appsec
• The MR includes necessary changes to maintain consistency between UI, API, email, or other methods
• Security reports checked/validated by a reviewer from the AppSec team

app/assets/javascripts/environments/components/empty_state.vue

@@ -2,14 +2,6 @@
 export default {
   name: 'EnvironmentsEmptyState',
   props: {
-    newPath: {
-      type: String,
-      required: true,
-    },
-    canCreateEnvironment: {
-      type: Boolean,
-      required: true,
-    },
     helpPath: {
       type: String,
       required: true,
@@ -28,18 +20,8 @@ export default {
           s__(`Environments|Environments are places where
         code gets deployed, such as staging or production.`)
         }}
-        <a :href="helpPath"> {{ s__('Environments|Read more about environments') }} </a>
+        <a :href="helpPath"> {{ s__('Environments|More information') }} </a>
       </p>
-
-      <div class="text-center">
-        <a
-          v-if="canCreateEnvironment"
-          :href="newPath"
-          class="btn btn-success js-new-environment-button"
-        >
-          {{ s__('Environments|New environment') }}
-        </a>
-      </div>
     </div>
   </div>
 </template>