Bump target frameworks of C# programs from netcoreapp1.0 to netcoreapp2.1

[ObsidianMinor]

Moved global.json up to root of repo, changed SDK version to 2.2.100.
Changed .NET Core SDK in dockerfile for kokoro to version 2.2.100.

.NET Core 1.0 is reaching end of life, it's hard to install, and it's getting in the way of everyone's fun.

This should fix issues with #5802

[ObsidianMinor]

@acozzette can you run a kokoro build to make sure this works?

[acozzette]

Sure, I just added the tag to start the build.

[jtattermusch]

This will need a run of https://github.com/protocolbuffers/protobuf/blob/c3340b20a8dbf230ddbc68096ea1e8631317d528/kokoro/linux/dockerfile/push_testing_images.sh to make sure the updated docker images are available.

[jtattermusch]

I pushed a few more changes to this PR - basically introducing a separate Dockerfile for C# tests (which seems to be in alignment with what protobuf team has been striving to do) - I was getting errors when re-building the multi-language Dockerfile

[jtattermusch]

@anandolee @TeBoring can you give me push access to https://hub.docker.com/u/protobuftesting or build and push the C# docker image from this PR yourself? (my dockerhub ID is https://hub.docker.com/u/jtattermusch)

https://github.com/protocolbuffers/protobuf/blob/c3340b20a8dbf230ddbc68096ea1e8631317d528/kokoro/linux/dockerfile/push_testing_images.sh

[ObsidianMinor]

Why do we call the dll directly instead of dotnet run --no-build?

[jtattermusch]

I personally feel more confident that this will really only run the pre-built dll as opposed to to running a dotnet command that can potentially do something extra. No reason to change this in this PR.

[jtattermusch]

I pushed the new testing image for C#, restarting tests.

[jtattermusch]

The new docker image seems to be working fine, but the c# compatibility test is now failing with
https://source.cloud.google.com/results/invocations/95f1e9c3-988e-46b3-9875-ec63b2cd6564/log. Any idea what's wrong? Help is appreciated.

+ cp ../../../src/protoc protoc_1
+ cp old_protoc protoc_2
+ run_test
+ ./protoc_1 -Iprotos/src -I../../../src/ --csharp_out=src/Google.Protobuf.Test --csharp_opt=base_namespace=Google.Protobuf protos/src/google/protobuf/unittest_import_proto3.proto protos/src/google/protobuf/unittest_import_public_proto3.proto protos/src/google/protobuf/unittest_well_known_types.proto
./protoc_1: error: '/tmp/protobuf/protobuf/csharp/compatibility_tests/v3.0.0/.libs/protoc' does not exist
This script is just a wrapper for protoc.
See the libtool documentation for more information.
+ FAILED=true
+ docker rm -f build_and_run_docker_490e5066-dae0-49b4-8620-d4d8d44a628d
build_and_run_docker_490e5066-dae0-49b4-8620-d4d8d44a628d
+ '[' -z true ']'
+ exit 1
[ID: 7381063] Build finished after 273 secs, exit value: 1

[ObsidianMinor]

Original was debian:latest, why change it to stretch? Could this cause the issues we're seeing with compatibility testing?

[jtattermusch]

currently latest = stretch, but meaning of debian:latest can change over time, and the idea of the docker image is to provide a stable runtime environment, so pinning to a specific version seems as a logical choice.
In the past, when debian:lastest changed from jessie to streche, that broke many of our dockerfiles.

[ObsidianMinor]

The only difference I can see between the last successful run I can find (22 days ago) and this one is that the base image was updated from Debian 9.7 to 9.8 but I don't know if that's the issue (I highly doubt it is).

We could just change the script to use path variables rather than copying files. I believe it'd easier to understand and manage that way in the long run.

[ObsidianMinor]

Try the tests one more time @jtattermusch

[jtattermusch]

the required dotnet SDK was not available on Kokoro Windows workers, so I added a script to install the right version of SDK before starting a windows build.
5e3e9fb

[jtattermusch]

I think the PR is ready for review and merging now.
Please doublecheck the sanity of changes to the compatibility script in
0efbd9a while reviewing.