Remove LogStream writers from Engine

[Zelldon]

Description

Part of #9600

In the current state the TypedProcessors (which might become the Engine later) and other entities, like JobTimeoutTrigger, DeploymentDistributor etc. have knowledge about how to write Records to the LogStream abstraction. Ideally, they shouldn't care about that detail. In the end, it would be great if the Engine can get something in and produce something out. For that we have to do some pre-work like removing the actual LogStreamBatchWriters usage and reduce related interfaces.

In the POC #9602 we split up the implementation of the TypedStreamWriterImpl so that it just writes into a wrapped buffer. This allowed to pre-claim that buffer in the start, and initialize the Engine with that Writer. This means we can reduce the dependency to the LogStream (helps when we split the Engine and the StreamPlatform). Later we renamed the Writers to something like Builder, but this is discussable.

See Writers in #9602 (comment)

Todo:

• Implement TypedStreamWriter that writes to a ByteBuffer #9780
  • Copy the content from TypedStreamWriterImpl to a new class
  • Remove the LogStreamBatch usage from that class, write directly into a pre-claimed buffer
• Add a new method to the LogStreamBatch
• Write tests for LogStreamBatch
• made the canWriteEvent method public on the LogStreamBatchWriter in order to use it in the RecordBatch
• Iterate over BufferedProcessingResultBuilder #10001
  • Replace with RecordBatch
  • Use RecordBatch everywhere
• Write tests for `BufferedStreamWriter #9838
• Decouple ProcessingResult from Log and Command writer #9998
• Find a good new name for the Writers Interface, including Command-, Rejection-, StateWriter. In the POC [POC]: Engine Abstraction #9602, we called it Builders, because wanted in the end build a list of Records. But maybe we can also use a different name here.
• Create a new Result Interface / Class which can be returned by the Engine
  • The Result can for simplicity return a BufferWriter like we did in the POC [POC]: Engine Abstraction #9602 (we can improve that later), but we can also just return a list of Records if you find a good way for it
  • Result should be used by Processing and ScheduledTasks to return Results
• Engine should return the result - ⚠️ here we need the Stream Processing changes first Refactor StreamProcessor / Engine #9725
• Use result in platform, write the records to the LogStreamBatchWriter
• Bonus: The result contains only the list of the records (instead of the general Buffer or BufferWriter)
• Bonus2 The serialization is done in the StreamPlatform on writing to the LogStreamBatchWriter
• We might need to adjust some tests

[Zelldon]

There was a comment regarding the naming by @saig0 maybe we consider this here #9602 (comment)

[Zelldon]

There was a comment by @npepinpe regarding to the serialization and the Result class:

#9602 (comment)
Should the engine implementation actually serialize the outputs?
Pros: frictionless, no need to interact with the distributed, easier to extend later if we add different processors.
Cons: more complicated for testing, embedding, possibly need to implement own integrity checks, schema evolution, not reusing the expertise of the distributed team regarding persistence.
I personally lean with Peter on having "record in -> record(s) out" instead of dealing with (de)serialization.