[DEVEX-222] - Auto serialization feedback improvements

[oskardudycz]

This PR follows up on the initial PR that introduced auto-serialization and applies the discussed changes.

1. Brought back expected stream state to append to stream methods. Even if users may decide to ignore optimistic concurrency check by using StreamState.Any and it may be a valid decision, we want to promote using optimistic concurrency and making it a cautious decision to resign from it.

2. Introduced of OperationOptions, which wraps common settings like deadline and credentials. I used it as the base class for reading, appending, and internal implementations. That's also aligned with the current Java client approach. This can be also preparation for future changes like batch appends.

3. Introduced MessageData and used it instead of EventData. As we want to promote KurrentDB as a general message store, and introduced Message type as a wrapper for the serialization then it's a logical step. Made EventData be possible to cast to message map to make easier migration and marked it as obsolete. Also applied some usability improvements in those classes (boy scout rule).

4. Added raw append to stream with options to give people a clear path when they want to provide raw bytes. Thanks to that, other append methods with dozens of parameters were obsolete and moved to extension methods. This should be less confusing, as now we have two official paths: auto-serialization and raw appends. The rest are clearly stated as obsolete.

5. Added DeserializedData and DeserializedMessages extension methods for read results. Thanks to that, people can easily map message data if they don't want to use the full ResolvedEvent. That makes clearer usage path for folks that offload all serialization and message mapping to us. You can use it as:

List<Message> deserializedMessages = await kurrentDbClient
    .ReadStreamAsync(stream)
    .DeserializedMessages()
    .ToListAsync();
		
List<object> deserializedDomainMessages = await kurrentDbClient
    .ReadStreamAsync(stream)
    .DeserializedData()
    .ToListAsync();

6. Besides that, simplified the MessageSerializer. Now it creates a derived serializer merging operation settings with default settings if needed. That allowed hiding internal details, and there's no need to pass content type explicitly, as it's already in settings.
   Extended SchemaRegistry will provide wrapper methods for naming the resolution context. Thanks to that MessageSerializer doesn't need to reference it internally.
   To make responsibilities clearer, made also naming resolution context part of the serializer context.

7. Aligned metadata serializer with the default, system one. Those settings will be different than the ones in regular data, but this will ensure that changes are backward compatible to tracing, etc, made by existing users.

TODO:

• Make old read methods obsolete,
• Make old subscription methods obsolete.

[yreynhout]

Looking good to me

[yreynhout]

Minor, but had me go "why?". Did it become nullable perhaps?

[oskardudycz]

Yes, and no 🙂

Yes because ThrowOnAppendFailure indeed is nullable now, as it can be provided or not by the user. I prefer to keep it nullable to have clear information whether the user sets it or not.

No because it's different OperationSettings than before. Previously we used here KurrentDBClientOperationOptions, which are general settings for the client, and it contains various options that may not be related to specific operations. Previously they were passed even to read operations, where ThrowOnAppendFailure wouldn't make any sense. I replaced them with more explicit and contextual AppendToStreamOptions and generic OperationOptions.

[yreynhout]

Was the intent for these to carry an [<Obsolete(...)>] attribute?

[oskardudycz]

Yes, good call! I forgot to mark them as obsolete. Did that in 1a8e507.

[CLAassistant]

All committers have signed the CLA.