Simplification of onboarding process

For gitlab projects, maintainer has the right to add CI variables to the project. But the developer does not have any such rights. So, the onboarding should be broken to the following steps: 

1. First time (and most likely, one time) Maintainer onboarding
   1. Take Gitlab URL, Token, Project path
   2. Process:
      1. Verify Qt account
      2. Verify Gitlab project
      3. Create list of CI / CD variables
      4. Add or update them to project
   3. Possibly, store this information some where in a database - that "THIS PROJECT" is using "QT CI" so that when developer goes through their onboarding, then they get the right message.
   4. KNOWN ISSUES in this case:
      1. All CI build will run the with DOCKER AUTH of maintainer
      2. If the maintainer loses Qt account access, the CI gets affected
      3. If the maintainer creates or onboards another project using thier Qt account, this project should also be updated
   5. Things to support in future
      1. Store the list of projects under one maintainer's Qt account
      2. A dashboard on our microservice to list all the projects that use Qt account + possibility to update their DOCKER AUTH CONFIG (at least)
2. Developer onboarding
   1. **Take Gitlab URL, Token, Project path
   2. NO access to CI / CD variables
   3. NO access to Webhook creation
   4. Process:
      1. Verify qt account
      2. Verify the Git project
      3. Create config file with DOCKER_USER and DOCKER_PASS
      4. Configure local docker utility to work with DOCKER_USER and DOCKER_PASS, e.g. `qt-docker-pull`
      5. Store config

Other things to check: 

• Can a developer do GIT PUSH WITH OPTIONS?
• Can a developer trigger a build and get access to view build variables?
• Can a developer trigger a build with different ENV variables?
• How to notify developer of different events like PUSH, Build complete etc