Support live repositories (per push tarantool builds)

[Totktonada]

Now this action only supports so called release repositories. Those repositories contain released tarantool versions (which are marked as x.y.z-0-gxxxxxxxxx).

It looks worthful to add so called 'live' repositories, which contain per-push builds. It may be useful for developers, which want to catch possible problems prior to actual tarantool release.

[rosik]

Both this issue and #12 has a single problem. Once a version is installed it's cached.
A user could drop the cache manually (either updating cache-key or specifying precise version), but I don't see a way to reinstall tarantool when the new version is out.

It could be possible if there were some API on tarantool.org that would say that e.g. the latest version in live/2.8 is 2.8.0-4. Then we could use it as a part of the caching key.

[Totktonada]

We discussed it a bit with Yaroslav.

Summary:

• The main problem is that we should decide whether to restore a cache before we'll enable the repository (otherwise we'll not save much time with caching).
• We can directly fetch repository metadata and look at the last tarantool version available. It'll hopefully eat less time than repositoty enabling (just one HTTPS request, not many ones).
• If we have the last version cached — use cache. Otherwise go to the slower path.

Example for Ubuntu:

$ curl -SsfL https://download.tarantool.org/tarantool/live/1.10/ubuntu/dists/xenial/main/binary-amd64/Packages.bz2 | bzip2 --decompress | grep -A 3 '^Package: tarantool$' | grep Version | sort | tail -n 10
Version: 1.10.8.66.gbad13ec-1
Version: 1.10.8.68.g6997264-1
Version: 1.10.8.69.g723fcb1-1
Version: 1.10.8.70.g107ad3f-1
Version: 1.10.8.71.g720ffdd-1
Version: 1.10.8.7.g31f26ac-1
Version: 1.10.9.0.g720ffdd-1
Version: 1.10.9.3.g5b9d71d-1
Version: 1.10.9.4.g6f0898a-1
Version: 1.10.9.6.gc954725-1

(Sorting is alphabetical, sure, it is just to show an example.)

Example for CentOS (after #11):

$ curl -SsfL https://download.tarantool.org/tarantool/live/1.10/el/7/x86_64/repodata/primary.xml.gz | gunzip | grep '<location.*tarantool-[0-9]' | sort | tail -n 10
<location href="Packages/tarantool-1.10.8.66-1.el7.x86_64.rpm"/>
<location href="Packages/tarantool-1.10.8.68-1.el7.x86_64.rpm"/>
<location href="Packages/tarantool-1.10.8.69-1.el7.x86_64.rpm"/>
<location href="Packages/tarantool-1.10.8.70-1.el7.x86_64.rpm"/>
<location href="Packages/tarantool-1.10.8.71-1.el7.x86_64.rpm"/>
<location href="Packages/tarantool-1.10.8.7-1.el7.x86_64.rpm"/>
<location href="Packages/tarantool-1.10.9.0-1.el7.x86_64.rpm"/>
<location href="Packages/tarantool-1.10.9.3-1.el7.x86_64.rpm"/>
<location href="Packages/tarantool-1.10.9.4-1.el7.x86_64.rpm"/>
<location href="Packages/tarantool-1.10.9.6-1.el7.x86_64.rpm"/>

Ideally we should read repomd.xml for location of the primary.xml.gz file, but we don't plan to rename it in a foreseeable future.

[Totktonada]

We plan to revisit our release policy and it is possible that we'll deprecate live repositories in favor of frequent pre-releases (alpha/beta/rc) that are carefully made by a human with a proper description. Not sure how exactly we'll deliver those pre-releases.

[Totktonada]

NB: It would be useful even without any caching for 'live' installs.

[rosik]

Without caching it's a single line in a workflow:

- run: curl -L https://tarantool.io/live/2.6/installer.sh | bash