github-ci: add reusable testing workflow

[ylobankov]

The idea of this workflow is to be a part of the 'integration.yml'
workflow from the tarantool repo to verify the integration of the
go-tarantool connector with an arbitrary tarantool version.

This workflow is not triggered on a push to the repo and cannot be run
manually since it has only the 'workflow_call' trigger. This workflow
will be included in the tarantool development cycle and called by the
'integration.yml' workflow from the tarantool project on a push to the
master and release branches for verifying integration of tarantool with
go-tarantool.

Part of tarantool/tarantool#6607
Part of tarantool/tarantool#5265
Part of tarantool/tarantool#6056

Related to tarantool/tarantool#6615

[DifferentialOrange]

To be honest, it's hard to run CI pipeline in head to test its ability to work, and I don't see any actions in Actions history. But it seems adequate. I have a couple of questions.

First of all, test runs only main folder tests. There are also submodules (not git sumbodules, go packages inside a package): queue and multi (and uuid after #104 merge) which have their own tests. I think it is worth to run them in CI too. It may be troublesome since current test environment setup is manual -- you need to start a different tarantool for each module, and there are no prepare (like mkdir snap xlog) or cleanup scripts. Moreover, some modules tests may be outdated or broken (I ensured that uuid tests work fine, but it seems there may be some troubles with user grants in queue test). I think it is worth to build a working test environment first and then run it with required artifacts. But it seems like a separate task and I'm not sure that any team have it in their plans.

The second question is related to the first one. If we are setting up CI for Tarantool integration, why not set up CI with classic on-push test run? Again, it looks like it is not the part of your task. But it seems weird for me that we will have integration pipeline and not have most simple and useful pipeline with test run per-push.

[ylobankov]

To be honest, it's hard to run CI pipeline in head to test its ability to work, and I don't see any actions in Actions history. But it seems adequate. I have a couple of questions.

First of all, test runs only main folder tests. There are also submodules (not git sumbodules, go packages inside a package): queue and multi (and uuid after #104 merge) which have their own tests. I think it is worth to run them in CI too. It may be troublesome since current test environment setup is manual -- you need to start a different tarantool for each module, and there are no prepare (like mkdir snap xlog) or cleanup scripts. Moreover, some modules tests may be outdated or broken (I ensured that uuid tests work fine, but it seems there may be some troubles with user grants in queue test). I think it is worth to build a working test environment first and then run it with required artifacts. But it seems like a separate task and I'm not sure that any team have it in their plans.

The second question is related to the first one. If we are setting up CI for Tarantool integration, why not set up CI with classic on-push test run? Again, it looks like it is not the part of your task. But it seems weird for me that we will have integration pipeline and not have most simple and useful pipeline with test run per-push.

Ok, let's set up a simple CI first (PR #116). The queue testing is commented out for now due to #115. So we need to fix #115, then merge #116.

[Totktonada]

No objections from me.

It would be nice to see a testing job.

[ylobankov]

No objections from me.

It would be nice to see a testing job.

Manual test run.