Create Knowledge Graph admin endpoint

What does this MR do and why?

• Introduce a new knowledge_graph_enabled_namespace table which is intended to be used to track which namespace have access to the Knowledge Graph and which don't.
• Introduce a new feature flag for knowledge graph features, called knowledge_graph which is tracked in #583676.
• Introduce new admin endpoints which allow to managed the enabled namespaces until it is properly integrated into the product.
  • PUT /admin/knowledge_graph/namespaces/:id
  • GET /admin/knowledge_graph/namespaces
  • DELETE /admin/knowledge_graph/namespaces/:id
• Sets the base for creating a ChatOps command which creates a better UX around this action (see gitlab-com/chatops!624).

Why not re-use p_knowledge_graph_enabled_namespaces

• That table was designed for indexing at the project level, which is not aligned with our current need.
• We only stores top-level namespaces who have access to the Knowledge Graph. Give the expected scale, we don't need to partitioning from the other table.

References

This merge request addresses part of #582318

Tests

This merge request was tested as part of gitlab-com/chatops!624, see the test result in the description of that merge request.

How to set up and validate locally

• Follow the steps described in Draft: feat: Add Knowledge Graph enable and dis... (gitlab-com/chatops!624) to test the commands locally.
• Start your GDK locally, create and admin token and ping the endpoint for any existing namespaces. The namespace should be enabled if it's a top-level namespace.

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.