Add 'review' functionality

[Gerold103]

At this moment TarantoolBot is able only to create documentation issues on pushed commits and closed issues. But there is another place with a great deal of chaos, which can be fixed by that bot - tarantool-patches mailing list. We could create a new bot or extend this one so as it scans tarantool-patches and sorts it out into tracks.

For each issue the bot maintains a track. The track contains the newest branch, link to the issue, reviewers list, version number and other info. When a reviewer writes a special command in that mail thread, like 'TarantoolBot lgtm', the bot notifies one of the maintainers, and set 'ready to push' label on GitHub. When a maintainer pushes the patch and the issue is closed - the track is removed.

To persist the tracks GitHub could be used. A track info could be stored in the issue comments.

[Totktonada]

I also thought about linking information that an issue contains with information that appear in a mailing list. A bot can track maillist discussions and link them into an issue.

However we plan to setup patchwork that will track maillist discussions. Maybe it worth to automatically link a patchwork thread into an issue and that is all.

Maybe I need to file a separate issue about that, but now it is not clear how things should look at the end.

[Gerold103]

I am afraid, that it makes no sense to duplicate patch discussions in the issues.

1. Usually, they are linked with certain patch parts, which would be extremely hard to extract from the letters and force the team to use some strict formatting during discussions. It is ridiculous, but only 2-3 people in the whole team are able to format their week reports correctly. Formatting discussions would be even harder;
2. Patch discussions are threaded and looks like a huge tree. However, GitHub issue comments does not support threading and branching;
3. It will annoy when your every single message is copied into GitHub, and it sends to you a GitHub notification with your own words;
4. It will not work for the patches without an issue;
5. These discussions would pad out the issue's comments, and overwhelm comments from customers.

The point of catching emails from the list is not in storing all the information on GitHub, but rather vice versa. Personally, I am very reluctant about setting GitHub labels like 'ready to review', 'ready to push', 'ready to fuck off ...'; about asking maintainers to push something; about trying to find the most actual branch of an issue. And I want those things automated.

[Totktonada]

There are no reasons to link each message into an issue. Just a start of a discussion (freelists, mailman or, better, patchwork) tree. Maybe a link for each patch version (because they are in separate trees).

[Totktonada]

I guess that this pain now disappears, because we're using GitHub pull request for reviews. Even if we'll implement some automation around pull requests, it is now easier to do using GitHub Actions (and it'll be more reliable).