Start migrating CI to Github Actions

[RadicalZephyr]

Templates aren't directly a feature in Github Actions, so I'm not going to attempt to parameterize the jobs the same way right now. Also, the on: conditions are so that the CI will fire on this PR while I'm developing it, the commented out version below is the correct final condition.

[RadicalZephyr]

First step

As @carllerche suggested, I'm breaking this project up into stages. For now, I've recreated the tests specified in ci/azure-test-stable.yml in github actions. The new test_tokio.yml file should run effectively the same set of test cases as this section of azure_pipelines.yml:

# Test top level crate
- template: ci/azure-test-stable.yml
  parameters:
    name: test_tokio
    rust: stable
    displayName: Test tokio
    cross: true
    crates:
      - tokio
      - tests-integration

# Test sub crates
- template: ci/azure-test-stable.yml
  parameters:
    name: test_linux
    displayName: Test sub crates -
    rust: stable
    crates:
      - tokio-macros
      - tokio-test
      - tokio-util
      - examples

Differences

Technically, it does slightly less work than the azure pipelines file since the "tokio - cargo test --features full" tests aren't run twice each on linux by the template inclusion in that second step. Let me know if that was desirable and not in fact redundant.

There is a substantial difference in how the work is partitioned into jobs (I think). Because Github Actions doesn't have any analogs for the template inclusion or looping functionality in Azure Pipelines, I used the build matrix to run the same set of cargo invocations on the same platforms. So instead of four runners, there are 13.

I also haven't yet included the functionality from azure-is-release.yml because I haven't looked into how it interacts with the rest of the pipeline and I don't think it affects anything in what I've implemented so far.

Test Results

Test results can be seen in my personal fork of Tokio

[taiki-e]

What do you think about moving yaml file to shell script (like rust-lang/rust#65202)?

(Personally, I think it may reduce the burden of migration (especially about the difference between syntax and supported features). In fact, the crossbeam's tests were written in shell script, which made the transition easier (but it's not as complicated a CI setting as tokio): https://github.com/crossbeam-rs/crossbeam/pull/489/files)

[RadicalZephyr]

Most of the same features are supported, and it was pretty simple to replace the usage of loop with using the job matrix.

I think test_cross_subcrates is really the only job that has enough commands in the body using an external script file would make sense, I'll see what it looks like to do that.

[taiki-e]

I've left a few nits about removing duplicate settings, this looks great overall!

[taiki-e]

Thanks!

[taiki-e]

I merged this & I opened #2559 to track the migration of the remaining of the jobs.

[carllerche]

@RadicalZephyr thanks for getting this started and @taiki-e for following up 👍