Workflow and git labels (draft)

1. A developer opens a PR with the label area/<what part of application changes were made>. When it is no longer a draft, a developer adds reviewers and puts the label On Review.
   1.1. When the task is completed and the PR can be built and deployed, a developer adds Ready for Testing label. It would be a signal for testers to start working on the PR verification.
2. After a tester verified the current state of code in PR (it's not necessary to have the approved PR at this moment), a tester replaces Ready for Testing label to tested.
   2.1. If a tester finds the task is not properly solved (contains bugs, not covers all requirements to close the task, or other concerns), a tester removes the Ready for Testing label and returns it to the development with the comment describing what is required to be fixed.
3. If a developer needs to change something in a tested PR, then after pushing changes, a developer removes the tested label and returns Ready for Testing label. This signals to testers that this PR was changed and new testing is needed (the test code might require changes as well).
4. Steps 2-3 can be repeated several times.
5. When a PR is approved, the label tested was put last time AFTER the pushing of last commit to PR, a developer replaces the On Review label with Ready to Merge one.
6. ...
7. PROFIT!

Note: ideally, all of the above is automated with the tools provided by GitHub: https://github.com/telstra/open-kilda/issues/5077