spike: security risks with web onboarding

At this moment, the onboarding process is provided in "CLI" mode and "WEB" mode. In both the cases, the actual onboarding script also deals with Qt account credentials (for authentication). Plus, the onboarding scripts are located on user's computer. 

Technically, someone will ill intentions can do the following: 

• Onboarding-web happens over HTTP and not HTTPS. So, anyone can snoop into the data and read secrets, especially:
  • Qt account email, password (severity high)
  • Gitlab Private token (severity low - token can be revoked)
  • NGrok authentication token (severity low - token can be revoked)
• Read or print the username and password of Qt account by editing the onboarding-python-script.py

How to deal with it? In the pilot version, I think its ok to move ahead with these risks. We can still safeguard ourselves of above mentioned risks by putting a specific "Terms of usage" for the plugin which defines what the user can do and what they cannot do during the pilot - without mentioning the above risks. Something like: "The user must understand that this is the pilot version of the software, which means, there may be certain malfunctions or reduced features. Even if it seems obvious, user is not allowed to tamper with any of the scripts etc etc".  After pilot, we should consider one or more of the following: 

Secure: Move all the on-boarding process online

Generate the config file which user can download on their computer and start the "qtci-run-plugin -c /path/to/this/qtcloud.config". This seems like a good approach but then we will have to change a couple of things about how our plugin reads data from `.git/config`. 

For example, when running the plugin for the fist time, we will ask the user where they have cloned the "git repo" and if not, clone it for them to a path and add this information to the "qtcloud.config". 

Then remove all such data in the plguin code which might be dealing with secure things. The code on user's computer should only read the "qtcloud.config" and do operations based on data stored in that file.

Note - this still needs a "two step process" but we can hide this from user and move the "second step" of configuring the plugin in "run-plugin" script itself. 

Run on-boarding on HTTPS:

Not really possible because we are opening the http://localhost:8086 and it will not be possible to generate a secure certificate for localhost. Unless, we are OK with having an invalid SSL certificate. 

Provide the plugin files as python-compiled code or exe. 

**So that there is an additional layer of security - but it cannot really stop a determined user from penetrating. 

It must be noted that security concerns are only for onboarding process because it deals with username, passwords etc. In the normal plugin code - we just read config and call the relevant APIs using the API key. Which IMHO is OK and standard way of any application to work.