Rework CI/CD

[asafpamzn]

CI platform has became a major limiting factor for a robust development, as was evident during 1.2 release.
As the amount of supported configurations grow, having the full CI test completing in 20+ hrs is unacceptable.
The primary weak point is the current implementation of a self-hosted runner which is a single EC2 instance, managed manually. This approach is obviously not scalable.
Instead, we should consider using docker-based approach with AWS fargate service.
In addition, we should consider doing so not only for the tests running on self hosted, but for all the tests since it will potentially be more scalable (bypassing github concurrency limitations).

Additional improvements to consider

redis-rs CI is taking too much time to finish — need to be shortening and improved:

• Strap unneeded cases: features, sync tests, versions tests etc.
• Fix usage of hard codded ports for server and run in multithreaded.
• Run tests with cargo nextest

Glide enhancement

• Using cache Rust builds for non Rust changes PR's.
• Some language build and test can be replaced by much faster tools, replacing them will make Glide CI and CD faster.
• Moving macOS runner to be a container of macOS on Ubuntu, saving CI costs. Can be done easily using services field of a job.

Also to consider #2544

[ikolomi]

The first issue that need to be addressed is the self hosted runner - it is the main bottle neck since the jobs run sequentially and often requires manual maintenance.

The alternative which is currently being studied is switching to kubernetis cluster that is supported by github actions.
Regardless of salable compute infra that will be eventually selected (EKS, ECS) the scaling requires updating the workflow files since they are written with assumptions that the jobs are running on the same host.
EE 14d