Support extending NEST types by deriving and implementing properties

With the move to utf8json in #3493, the serialization of NEST types is strict, serializing only those properties specified on implemented interfaces in many places. For example, PropertyFormatter only serializes the I*Property interface members:

https://github.com/elastic/elasticsearch-net/blob/f3ec7198a979da2fe11ef8e14fbe69b072c92a43/src/Nest/Mapping/Types/PropertyFormatter.cs#L97-L192

With such strictness, it is not currently possible to derive a type from a NEST type, add additional properties, and have those properties serialized by the internal serializer. This is demonstrated in InjectACustomIPropertyImplementation()

https://github.com/elastic/elasticsearch-net/blob/e2b7f7529976d8a47a8db37d9dbb6b6bbcd8d253/src/Tests/Tests/ClientConcepts/HighLevel/Serialization/ExtendingNestTypes.doc.cs#L53-L97

utf8json is able to support this feature through using the fallback formatter, DynamicObjectTypeFallbackFormatter ,exposed by resolving a IJsonFormatter<object>, which internally inspects the type and generates a custom serialization method for it, caching it in a ThreadsafeTypeKeyHashTable<KeyValuePair<object, SerializeMethod>>. This path looks like it would be a plausible way to support extending NEST types but requires some guarding when serializing Attribute types; when a type to serialize is an Attribute type, the walking of properties performed by MetaType traverses down to a framework enum type with multiple members with the same undelying value, which trips up the EnumFormatter. For an Attribute type, this walking should not be performed.

[russcam]

I’m going to close this issue and open a new specifically to track extending token filters https://github.com/elastic/elasticsearch-net/issues/3655#issuecomment-512823453

[bonny-bonev]

Hi again. The solution you suggested seems to work for us at this point. Thank you very much!