Add an API to provide the reason / what is being requested in IO

[alamb]

So we basically have a 2nd file parser here 🤔 I'm wondering if instead of creating yet-another-parser -- even though it's partial -- we could ask the decoder to provide us a "reason" or a "trace" on the individual read requests. For example, we could extend AsyncFileReader with an implemented-by-default method:

trait AsyncFileReader {
   // all the current methods stay!

   fn get_bytes_with_trace(&mut self, range: Range<u64>, trace: Trace) -> BoxFuture<'_, parquet::errors::Result<Bytes>> {
        // ignore trace by default
        self.get_bytes(range)
   }

   // same for the other two methods...
}

// bikeshed whatever `Trace` is, maybe use :http::Extensions?

Originally posted by @crepererum in #7971 (comment)

[alamb]

Copying my response:

we could ask the decoder to provide us a "reason" or a "trace" on the individual read requests.

This is a neat idea.

I definitely don't want to make AsyncFileReader and more complicated than it currently is 🤮

However, this could be fairly easily added to the Push decoder API here:

• [Parquet] Add ParquetMetadataPushDecoder #8080

Maybe instead of

/// This is used to communicate between the decoder and the caller
/// to indicate what data is needed next, or what the result of decoding is.
#[derive(Debug)]
pub enum DecodeResult<T: Debug> {
    /// The ranges of data necessary to proceed
    // TODO: distinguish between minimim needed to make progress and what could be used?
    NeedsData(Vec<Range<u64>>),
    /// The decoder produced an output item
    Data(T),
    /// The decoder finished processing
    Finished,
}

We could add something like

pub enum DataRequest {
  /// last 8 bytes
  Footer,
  /// Metadata at the eend
  Metadata,
  PageIndex,
  DataPage { row_group_index, page_index},
  Unknown,
...
} 


#[derive(Debug)]
pub enum DecodeResult<T: Debug> {
    /// The ranges of data necessary to proceed
    // TODO: distinguish between minimim needed to make progress and what could be used?
    NeedsData {
      trace: DataRequest
       ranges: Vec<Range>,
    },
    /// The decoder produced an output item
    Data(T),
    /// The decoder finished processing
    Finished,
}

🤔

[alamb]

@crepererum says

Yes, that's better. You're right that instead of using the async interface -- which is just one way to drive the push decoder --, we should use the push decoder interface directly to convey the trace/intend 👍