Enable observers to create final report

[stefan-k]

It could be useful to allow observers to collect data during the run and then optionally create a final report. There are however a couple of issues.

Observers are stored as dyn Observe (where Observe is a trait) inside a Vec in the Executor (ObserversVec to be precise). ObserversVec is defined as:

type ObserversVec<I> = Vec<(Arc<Mutex<dyn Observe<I>>>, ObserverMode)>;

where I represents the state, which is the same for all observers in a run.

They are not returned from the Executor. Even if they are returned from the Executor at the end of the run, all that is known is the interface, therefore creating the report probably needs to be part of the Observe trait. The report creation could look something like this:

pub trait Observe<I> {
    /// [...]

    fn report<R>(&mut self, _state: &I) -> Result<R, Error> {
        Ok(())
    }
}

Unfortunately that makes Observe not object safe and hence ObserversVec doesn't work anymore. Even if it were possible, it wouldn't work because if Executor returns the list of observers and the user calls report(..) on every observer, the resulting type depends on the observer, which is against how Rust works. I can't think of a "common" R that would work for all possible kinds of reports, therefore this has to be generic. The obvious alternative would be

pub trait Observe<I, R> {
    /// [...]

    fn report(&mut self, _state: &I) -> Result<R, Error> {
        Ok(())
    }
}

but that obviously doesn't work either because that requires all observers in ObserversVec to produce the same report.

A Report trait won't solve any of these issues either.

The only thing I can think of is some kind of ReportStorage, with interior mutability which is shared with the observer, where the observer can push information into. This storage outlives the observer and one can call report(...) on it afterwards. ReportStorage wouldn't be part of argmin as it would be highly dependent on what kind of report it produces. This could already be done with the current interface, but isn't straightforward to document.

Any ideas are highly welcome!