Adds error serialization-deserialization

[gabotechs]

Allows propagating DataFusionErrors over the wire so that upstream stages can read the original error without loosing information.

This is done by providing some mirroring protobuf messages for all the current variants of DataFusionErrors. As these errors might also hold references to other errors from other libraries, also those other error message get a mirroring protobuf message.

This PR ships a bunch of boilerplate code, but the actual important parts and the only ones that are exposed to the rest of the project are just two functions:

/// Encodes a [DataFusionError] into a [tonic::Status] error. The produced error is suitable
/// to be sent over the wire and decoded by the receiving end, recovering the original
/// [DataFusionError] across a network boundary with [tonic_status_to_datafusion_error].
pub fn datafusion_error_to_tonic_status(err: &DataFusionError) -> tonic::Status;

/// Decodes a [DataFusionError] from a [tonic::Status] error. If the provided [tonic::Status]
/// error was produced with [datafusion_error_to_tonic_status], this function will be able to
/// recover it even across a network boundary.
///
/// The provided [tonic::Status] error might also be something else, like an actual network
/// failure. This function returns `None` for those cases.
pub fn tonic_status_to_datafusion_error(status: &tonic::Status) -> Option<DataFusionError>;

Everything else is hidden in the src/errors/ modules

---

The PR ships both unit tests for all the error variations and an integration tests that checks that errors are properly propagated through the networks and can be recovered on the receiving end

[NGA-TRAN]

Very nice infrastructure, Gabriel. You make things very easy for us to send and use error

[NGA-TRAN]

Question: If a new error number 20 is added in the future, can we simply add 20 here without worrying about backward compatibility?
Also this means whenever we upgrade datafusion and there are new arrow (datafusion, parquet, ...) errors, we have to add them here (or in the right error file) right?

[gabotechs]

That's right. The only thing we cannot do is to tweak the order of the messages, or deleting numbers, but adding new numbers (and therefore error variants), is backwards compatible.

If there's a DataFusion upgrade and a new error variant is added, we'll need to come here and add it ourselves, otherwise the Rust compiler will tell us there are some error variants not handled.

[NGA-TRAN]

It will be perfect if we get compile error

[NGA-TRAN]

It is very nice that you make and put all Arrow, Parquet, Schema, Context, SQL parser,... error protos in here so we only worry about serialize and deserialize one type.

[gabotechs]

Yeah, it was quite a bit of work, but it's something that's probably going to need close 0 maintenance, and it's going to help us a lot in knowing what goes wrong.

I expect initially to see more errors than actual queries running.

[NGA-TRAN]

I am amazed reading this test. We do not have to convert anything here. You already deserialize and covert the error in arrow_flight_read.rs

[gabotechs]

Yeah, I expect these integration tests to be key not only for ensuring our changes remain healthy, but also for development and debugging.

If they feel like magic it means that we are on the right track.

[robtandy]

This makes sense to me and will allow for propagation of root cause errors; thank you @gabotechs !