Added support for controlling the op_type when indexing

[orjan]

In order to write to data streams we'll need to set the
op_type to create the default is index

In order to don't serialize null values for the batch action and to not depend
on custom serialization setting we're using LowLevelRequestResponseSerializer.Instance
for serialization of the action.

We won't throw exception when setting the TypeName to null since:

• This is deprecated in v7
• Won't work in v8

What issue does this PR address?

• Support for data streams Elastic 7.9 #355 It's possible to set the op_type to create by setting BatchAction to ElasticOpType.Create
• HTTP 400 when sending log to ElasticSearch 8.0.0 #345 It's possible to set TypeName to null to remove it from the payload being sent to Elastic.

Does this PR introduce a breaking change?
I don't think we have introduced an breaking change but we'll need to review the following changes to make sure they're not breaking.

• The custom serializer for the action has been replaced by a specific one, it's not impossible that someone has been intercepting this call for adding custom elements when logging.
  https://github.com/serilog/serilog-sinks-elasticsearch/pull/356/files#diff-15ec7bbc1a4d48125fae012ffb1896acR191

• Earlier and exception was thrown when trying to set the TypeName to null it's unlikely that someone has relied on this exception. https://github.com/serilog/serilog-sinks-elasticsearch/pull/356/files#diff-cb61ceb2dfe8091b1abe76e3c275d6d0L77

Please check if the PR fulfills these requirements

• The commit follows our guidelines
• Unit Tests for the changes have been added (for bug fixes / features)

Other information:

[mivano]

Thanks for this PR. Looks good. I agree with your points, the exception type does not look like an issue, the other one might be an issue. But that we can highlight in the changes.md and readme.md.

[orjan]

@mivano currently there's an issue with the error handling since when we're setting the OpType to create it won't work, since it's looking for index. Also there an open PR #284 trying to address another issue with error.

The question is would we like to stay with the DynamicResponse or are we open to de-serialize the response to DTO:s instead?

[mivano]

Another thing that crossed my mind; the durable part also sends data to ES in a similar manner, but using different code constructs. Most likely the same issue will apply here. For some while now I feel less comfortable with this durable part. It is a large part of the code base with a lot of duplication. And that last part makes introducing these changes more difficult. Besides, the durable functionality is not as stable as it should be and there might be better solutions if you want similar behaviour.

What is your take on this? Worthwhile to apply the same thing to the durable part, exclude it explicitly or something else?

[orjan]

Another thing that crossed my mind; the durable part also sends data to ES in a similar manner, but using different code constructs. Most likely the same issue will apply here. For some while now I feel less comfortable with this durable part. It is a large part of the code base with a lot of duplication. And that last part makes introducing these changes more difficult. Besides, the durable functionality is not as stable as it should be and there might be better solutions if you want similar behaviour.

What is your take on this? Worthwhile to apply the same thing to the durable part, exclude it explicitly or something else?

I did a quick fix for the durable part and there are 2 places that needs to be fixed, so I'll fix that as well.
I'm not sure what we should do about the duplicated implementations, in the best of world we should isolate the durable part to a separate lib or at least namespace if possible? Are there any other durable sinks with the same needs?

[mivano]

A totally separate discussion of course from this PR, but I would be inclined to remove it out of this sink and offer functionality in a different way. Preferable using a higher abstraction, so you can specify it on the serilog sinks level instead. This original implementation came from the Seq one (https://github.com/serilog/serilog-sinks-seq/tree/dev/src/Serilog.Sinks.Seq/Sinks/Seq/Durable) so there are more sinks with a similar feature. Problem is that I do not know how many users are actually depending on this durable feature. So it would be a real breaking change with or without another solution.

[mivano]

Merging it into dev so we have a prerelease package.