Consider alternative EventStream implementation

[mattfbacon]

For a lot of drivers, grouping of events matters. The current EventStream implementation doesn't expose their grouping so it is difficult to properly implement functionalities using such devices if you also want to be async.

I have implemented an alternative API based on the same FetchEventsSynced struct used by the sync event interface. mattfbacon@7660fe9

I think this makes more sense because it provides flexibility based on the grouping. e.g., users can adapt it to a Stream by flattening the event groups, or process each chunk directly when it matters.

[emberian]

hm, this is a major problem...

[mattfbacon]

I agree, hence my fork. What are your thoughts on those changes?

[coolreader18]

How would you feel about being able to opt in to that? Like, a separate next_event_batch function that returns FetchEventsSynced? I think it should be possible to have both; maybe range and consumed_to would be redundant but otherwise it should be possible.

[mattfbacon]

It's a possibility but I don't think it's really necessary because the unbatched version can be synthesized from the batched version, but not vice versa.