Shutdown behavior for groupbyprocessor

[jpkrohling]

When working on #1362, there was a discussion about what the shutdown behavior should be for the processor, regarding the in-flight traces:

what should happen with in-flight traces when the processor is shutting down? Should we just discard them? Should we flush them immediately, blocking until they are consumed, possibly honoring the context's deadline?

To unblock that PR, this issue here was created, so that the appropriate solution is agreed on, to be implemented as a follow-up PR.

[jpkrohling]

This should also be assigned to me.

[jpkrohling]

cc @nilebox, as you reviewed the original PR.
cc @pjanotti, @bogdandrutu and @tigrannajaryan for your opinions.

The groupbyprocessor's premise is to release traces to the next processor only when a trace has been completed. It's unclear what should be the behavior during the shutdown: should in-memory traces be discarded, as they are potentially incomplete? Or should them all be flushed, to give them a chance of being persisted, even if partially?

[tigrannajaryan]

I believe the desirable shutdown behavior is to stop receiving new data, drain all in-memory data from the pipeline, flush the exporters and exit the process. For groupbyprocessor this would mean flushing the accumulated (even if incomplete) traces to the next consumer. I do not think there is an expectation to wait for a trace to be complete before shutdown is complete.

[jpkrohling]

I think that's in line with @nilebox's opinions. I'll work on doing this then.