[otap-dataflow] parquet exporter gracefully handle errors

[albertlockett]

There are a few types of errors we may encounter in the parquet exporter:

Non-retryable errors:

• e.g. some message has malformed record batches

Retryable errors:

• e.g. temporary network failures or service interruptions make it so we can't write parquet to remote object storage

Misconfigurations:

• e.g. the bucket/storage location does not exist or can not be accessed

In each case, we should have a strategy for handling these.

For example, we may wish to emit a Nack control message which could suggest to the Retry processor whether it should retry the batch.

For the parquet exporter in-particular, careful attention will need to be payed to how we handle retried messages. For example, if we have written Logs to some file successfully, but LogAttrs for this batch fails for some retryable reason, we'll need to ensure that we:

• don't flush the Logs file until LogAttrs is finally retried, written and flushed
• don't rewrite the Logs message
  In this case, it might make the retry handling simpler if we don't even write the Logs message until we've sucessfully written LogsAttr. We can consider this more carefully when implementing this issue.

Prerequisites:

• [otap-dataflow] emit control message from pipeline components using effect handler #498
• [otel-arrow-rust] Control Processor, Retry, Failover #368

[lquerel]

Added more details on the Retry Processor in #509, and on the Failover Processor as well #510 (sub-issue of #368)