It seems that the last completed Travis build was 6 days ago, and
travis-ci.org is going to be shut down anyway.

As with travis, api_benchmark/query_benchmark have a single stage
which generates protos checks format and runs analyzer.

For protobuf and protoc_plugin I've split a single format_analyze_test
stage into three separate stages for a better control of OSes and Dart
SDK versions.

`protobuf` tests run on windows, linux, and osx, but `protoc_plugin`
tests run on linux only (we'd need a way to make `make protos` work on
osx and windows to enable tests).

Currently the pipeline takes about 16-17 minutes to run, mostly
because `make protos` for protoc_plugin takes around 2 minutes and
dartfmt check is slow (also around 2 minutes) for protoc_plugin and
query_benchmark. If this is an issue, we can potentially speed it by 4
minutes by merging all protoc_plugin stages into one (as tests run on
a single os anyway).

Fixes google#459

It seems that the last completed Travis build was 6 days ago, and
travis-ci.org is going to be shut down anyway.

As with travis, api_benchmark/query_benchmark have a single stage
which generates protos checks format and runs analyzer.

For protobuf and protoc_plugin I've split a single format_analyze_test
stage into three separate stages for a better control of OSes and Dart
SDK versions.

`protobuf` tests run on windows, linux, and osx, but `protoc_plugin`
tests run on linux only (we'd need a way to make `make protos` work on
osx and windows to enable tests).

Currently the pipeline takes about 16-17 minutes to run, mostly
because `make protos` for protoc_plugin takes around 2 minutes and
dartfmt check is slow (also around 2 minutes) for protoc_plugin and
query_benchmark. If this is an issue, we can potentially speed it by 4
minutes by merging all protoc_plugin stages into one (as tests run on
a single os anyway).

Fixes google#459

It seems that the last completed Travis build was 6 days ago, and
travis-ci.org is going to be shut down anyway.

As with travis, api_benchmark/query_benchmark have a single stage
which generates protos checks format and runs analyzer.

For protobuf and protoc_plugin I've split a single format_analyze_test
stage into three separate stages for a better control of OSes and Dart
SDK versions.

`protobuf` tests run on windows, linux, and osx, but `protoc_plugin`
tests run on linux only (we'd need a way to make `make protos` work on
osx and windows to enable tests).

Currently the pipeline takes about 16-17 minutes to run, mostly
because `make protos` for protoc_plugin takes around 2 minutes and
dartfmt check is slow (also around 2 minutes) for protoc_plugin and
query_benchmark. If this is an issue, we can potentially speed it by 4
minutes by merging all protoc_plugin stages into one (as tests run on
a single os anyway).

Fixes google#459

This brings the following changes from master branch:

- Support optional proto3 fields (#444)
- Fix handling of oneofs in dart proto3 json parsing. (#447)
- Use @Dart = 2.7 in generated files (#455)
- Migrate from Travis to GitHub Actions (#460)
- Emit binary coded descriptors from dart protoc_plugin. (#406)

Github Actions config modified to run only on dev sdk. Also modify analyzer flags to remove --fatal-infos, there's one mixin-related violation:

```
hint • The library 'package:protoc_plugin/testing/mixins.dart' is legacy, and should not be imported into a null safe library. • out/protos/mixins.pb.dart:12:8 • import_of_legacy_library_into_null_safe
```

Also slightly speeding up a build by removing make protos step from format stage: generated protos are not checked in and formatted anyway, but generating and checking format takes 3-4 minutes.

Co-authored-by: Sigurd Meldgaard <sigurdm@google.com>