feat: drone activation and otomi version upgrade with cypress

[ferruhcihan]

Implements:

https://app.zenhub.com/workspaces/dev-5e7e84dddc966f05a627a19b/issues/gh/redkubes/otomi-e2e/30

Description:

This PR adds features for drone activation and otomi version upgrade with cypress. User doesn't need to activate drone manually. Otomi drone activation job does this work for the user.

Is paired with: https://github.com/redkubes/otomi-console/pull/311

Changes Made:

Add drone activation job to activate repository
Add e2e job to upgrade otomi version

Testing:

• Open Deploy Otomi page

• Run workflow with feat/e2e branch

• After the cluster created check drone if it's activated

• Run workflow with feat/e2e branch and upgrade Otomi installation profile

• After the cluster created check drone if it's activated

• After the initial pipelines finished check otomi version if it's setted as main in otomi settings page

Checklist

• Architecture Design Records have been added as adr/*.md and appended to list in adr/_index.md, if applicable.
• The values-schema.yaml file and test/** fixtures have been updated to reflect code changes, if applicable.
• The OpenApi Schema from redkubes/otomi-api project is compatible with definitions from values-schema.yaml file, if applicable.
• Helm releases are meeting otomi's baseline security policies, if applicable.
• Helm chart and helmfile changes are tested against upgrade scenario, if applicable.

[j-zimnowoda]

Was thinking about the very first Otomi install and here are my thoughts.

There are two use cases that we need to cover on very first Otomi install:

1. activating the values repo
2. printing welcome message
   Those can happen only once during the very first install.

Since the Otomi job can fail and retry, we do not know if it is the very first install or not. Moreover some users calls helm install many times to deploy any consecutive changes in Otomi (they do not use Drone).

Therefor, I propose to:

• the applyE2e() is called as part of the otomi apply command (just after commit(true) call.
• print the welcome message after calling applyE2e()
  P.S.
  I would still provide the otomi e2e command as it proved to be useful

[j-zimnowoda]

For the e2e upgrade scenario.
I think that developers would like to test their feature branches. In order to enable it we actually need to first deploy the latests official release and then upgrade to feature branch.
It seems that it is not possible now. Could you modify the upgrade scenario so when a user select it:

1. The otomi is deployed with the latest official release (we can hardcode it for now)
2. The otomi is upgraded to the feature branch (see screenshot)