Add event stream design

[JordonPhillips]

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[alextwoods]

Is the shape serializer responsible for both serializing the shape and encoding the event stream message? In general for event streams, I had thought about these as two separate steps / responsibilities - a shape serializer generally would serialize into an event message and then a separate encoder would handle encoding to the binary wire format (and then a separate signer signs that message and re-encodes it).

[JordonPhillips]

Is the shape serializer responsible for both serializing the shape and encoding the event stream message?

It can be if that makes the most sense in a given scenario. Generally it would be better to do it that way because then you avoid having to allocate an intermediate representation. The need to sign events makes that impractical, however, because the signer needs to add headers.

Deserialization similarly would be better to stream off the wire, but it runs into another issue - async. ShapeDeserializers are synchronous, so we need to read the whole event and then pass it to the deserializer so that it can all be standard.

I had thought about these as two separate steps / responsibilities

This is some space I think could use a touch up in the implementation. Right now it's a bit of both ways. It works, but could be more efficient.

[jonathan343]

Why is pass being used here and not ...? Is this indicating that user's shouldn't need to provide their own implementation?

[JordonPhillips]

Correct. IIRC one of the type checkers enforces this sort of behavior.

[jonathan343]

This caught my eye because our implementation in packages/smithy-event-stream/src/smithy_event_stream/aio/interfaces.py uses ... instead of pass.

We should probably keep this consistent, but this is also just a design doc so not a big deal.