Give the ability to retain unknown properties when sending messages across microservices

[tomerc]

This is just a POC of an idea to retain unknown properties across microservices that have different versions of the pojos compiled into them see context here. I tried the changes I made to the velocity files as an override template in the Maven plugin and it looks to be working as intended. Would like feedback if this is something that is desired to be put into avro core.

What is the purpose of the change

Allow the ability to retain unknown properties across multiple microservices with different versions of the pojo compiled into them fixing AVRO-XXXX.)

Verifying this change

(Please pick one of the following options)

This change is a trivial rework / code cleanup without any test coverage.

(or)

This change is already covered by existing tests, such as (please describe tests).

(or)

This change added tests and can be verified as follows:

(example:)

• Extended interop tests to verify consistent valid schema names between SDKs
• Added test that validates that Java throws an AvroRuntimeException on invalid binary data
• Manually verified the change by building the website and checking the new redirect

Documentation

• Does this pull request introduce a new feature? (yes / no)
• If yes, how is the feature documented? (not applicable / docs / JavaDocs / not documented)

[opwvhk]

Although I understand the wish, making it work is going to be tricky. Also, I expect your use case to be solved by a partial implementation of this concept.

As such, I'd advise you to start without a PR (if you haven't already) by using the Maven plugin parameter templateDirectory.

As for the template, I'm missing a few things:

1. A field to store the current schema: the class schema is $SCHEMA, but instances have their own schema as otherwise serialising the record will drop the additional fields.
2. Additional constructors with an extra Schema parameter (defaulting to $SCHEMA for the constructors that don't have it). The constructors must validate compatibility, and throw if the given schema is incompatible (i.e., SchemaCompatibility.checkReaderWriterCompatibility($SCHEMA, schema).getType()!=COMPATIBLE).
3. Integer fields (one for each field in the compiled schema) containing the field positions in the current schema. You can then use these for the methods get(int) and put(int, Object), which must also handle default values for fields in $SCHEMA that are missing in the current schema.

Next, you'll need a subclass of SpecificData to handle the switch between compiled classes and GenericRecord/GenericEnumSymbol/GenericFixed. I have not delved into this yet, but at the very least you'll want to have a look at getSchemaName(Object), newRecord(Object,Schema), createEnum(String,Schema) and createFixed(Object,Schema).