AVRO-3446: Add avrogen unit tests

[zcsizmadia]

Make sure you have checked all steps below.

Jira

• My PR addresses the following [Avro Jira](https://issues.apache.org/jira/browse/AVRO-3446
  • https://issues.apache.org/jira/browse/AVRO-3446
  • In case you are adding a dependency, check if the license complies with the ASF 3rd Party License Policy.

Tests

• My PR adds the following unit tests OR does not need testing for this extremely good reason:

Commits

• My commits all reference Jira issues in their subject lines. In addition, my commits follow the guidelines from "How to write a good git commit message":
  1. Subject is separated from body by a blank line
  2. Subject is limited to 50 characters (not including Jira issue reference)
  3. Subject does not end with a period
  4. Subject uses the imperative mood ("add", not "adding")
  5. Body wraps at 72 characters
  6. Body explains "what" and "why", not "how"

Documentation

• In case of new functionality, my PR adds documentation that describes how to use it.
  • All the public functions and the classes in the PR contain Javadoc that explain what it does

[zcsizmadia]

@martin-g @RyanSkraba We have some work in progress and PR done for avrogen. This PR makes very minimal (non-functional) changes to avrogen, however it adds a good amount of testing for the code generation. IMO this could be a very solid base line testing before we make any changes to avrogen. This changes should mofify or add new unit tests. This way we have more confidence in the changes. I had a pending PR #1574 which had these unit tests, however I think it is a better sequencing if we add the baseline testing first to reflect and test the current avrogen status.

The tests include the following:

1. Command line sanity checks /w return codes
2. Compiling avro schemas into cs files AND compiling them with the runtime Roslyn compiler (DOM cannot be used in dotnet core). That old commented out code is revived by using the roslyn compiler,
3. Checking the generated cs files directory hierarchy
4. Checking the types included in the dynamically compiled assembly
5. Instantiate object for the the types included in the dynamically compiled assembly
6. Because of this I added a unit test GenerateSchemaWithNamespaceMapping_Bug_AVRO_2883 which validates that the https://issues.apache.org/jira/browse/AVRO-2883 bug is valid, since the compilation will fail. As soon as it is fixed with AVRO-3425: Extend C# avrogen namespace mapping to models and members as well #1574 that unit test can be removed since it will fail, becuase the issue is fixed
7. Namespace mapping for single objects, where the above bug is not a concern
8. Namespace mapping with reserved keywords in the namespace

If you agree we can prioritize this PR so, e.g. #1578 can add unit tests to validate the new skipped directory structure

[zcsizmadia]

The Travis CI support is very slooow. Is there anything that travis.yml covers, which is not covered by the git flow actions? Can it be retired? Many times Travis takes hours to be finished.

[KyleSchoonover]

I'm good with the intention of this, but I do want to break the functionality of the AvroGen class into a separate class. Keep the "program" entry point to just deal with parsing the input. The other option is taking advantage of the strong naming to sign the assembly.

[zcsizmadia]

Note that there is an AvroGenTests, for that reason. Most functionality will be moved to the libraryaa you said. And AvroGenToolTests will be the tool specific tests. This will be done in steps to make sure that current functionality is not altered by the actual rework.

[RyanSkraba]

Should this be cherry-picked to 1.11.1 ? It seems like a good candidate!

[zcsizmadia]

@RyanSkraba adding it to 1.11.1 makes sense. These unit tests IMO are a must have to provide a base line test coverage to the code generation and avrogen, which was not covered before.