[V2] New entry point for manager

🔵 This MR is part of the PoC implementation of Operator V2.

⚠ DO NOT MERGE BEFORE !782 (merged)

Summary

The new entrypoint makes it possible to use CLI to configure and control the runtime environment of the manager while keeping its compatibility with the legacy mode.

Motivation

1. Operator V2 needs to setup a Manager that will collide with the configuration of the controller runtime of V1. With the new entrypoint, Operator V2 can use its own configuration without impacting the configuration and functionality of V1.
2. The new project scaffolding is closer to the standard scaffolding of Go projects and newer versions of kubebuilder.

What does this MR do?

• The main.go file has been moved to cmd/manager/legacy/start.go.
• A new cmd/manager/manager.go file has been added as the new entry point for the application.
• The legacy command has been added to use the old entry point and supports running the controller and webhook for GitLab custom resources v1beta1.
• A new start command has been added to start controllers and webhooks for newer versions of GitLab custom resources.
• The new entrypoint is backward compatible and by default falls back to legacy command.

How to test it?

You can build the command locally, using task manager or use the Docker image from the pipeline, i.e. registry.gitlab.com/gitlab-org/cloud-native/gitlab-operator:hp-operator-v2-cli (if you do use the Docker file you just need to pass the command-line options since manager is the entrypoint of the image).

This is how the new manager CLI looks like:

# Default mode falls back to legacy CLI
$ manager --metrics-addr :8080 --zap-log-level info --zap-encoder console ...
# Manager log output

# Legacy mode
$ manager legacy --metrics-addr :8080 --zap-log-level info --zap-encoder console ...
# Manager log output

# New entrypoint
$ manager start [NEW OPTIONS] ...
# Not implemented yet. No message. Manager exists with non-zero code.

Checklist

See Definition of done.

For anything in this list which will not be completed, please provide a reason in the MR discussion.

Required

• Merge Request Title and Description are up to date, accurate, and descriptive
• MR targeting the appropriate branch
• MR has a green pipeline on GitLab.com
• When ready for review, MR is labeled "~workflow::ready for review" per the Distribution MR workflow

Expected (please provide an explanation if not completing)

• Test plan indicating conditions for success has been posted and passes
• Documentation created/updated
• Tests added
• Integration tests added to GitLab QA
• Equivalent MR/issue for omnibus-gitlab opened
• Validate potential values for new configuration settings. Formats such as integer 10, duration 10s, URI scheme://user:passwd@host:port may require quotation or other special handling when rendered in a template and written to a configuration file.