Reports as system-state Observers

[raof at ubuntu.com]

On a recent merge proposal¹, Alan wrote:

 >> Huh. I *guess* you could use the logging interface for detecting 
display
 >> configuration changes.
 >
 > You have that backwards. The reason we have the report interfaces is 
that there are things
 > that need reports from Mir that are not logging.
 >
 > I remember long discussions when we introduced reports about why we 
didn't just log directly.
 > This is an example of something that isn't logging or lttng.

I don't particularly mind using Reports as a method of system 
implementation², but I think that the current social expectation 
around Reports more closely matches “the various mir::report::* 
interfaces we have are fundamentally debugging aids, and correct system 
operation would not be impacted if we entirely removed them”.

As far as I'm aware, with the exception of ::new_configuration(), this 
is currently the case.

If we *are* going to treat Reports as something that shells can 
generically hook into to drive control flow we're going to need to be 
more careful about the environment we call them in. For example, 
currently if a shell hooks into new_configuration() and requests the 
base_configuration() we'll deadlock. I've not worried about ensuring my 
code doesn't hold any locks when calling into a Report, nor have I 
checked that during reviews, because I've expected the Report 
implementations to be roughly pure functions.

So, I'm happy for us to use Reports as a general introspection method, 
but I suspect that many on the Mir team don't currently think they are, 
and we'll need to change our behaviour if they are.

¹: 
https://code.launchpad.net/~raof/mir/notify-shell-of-display-configuration/+merge/305189
²: Modulo the concern that, currently, this means that we don't 
guarantee that debugging information is available, and a naive 
implementation hooking into a report will destroy its use as a source 
of post-hoc debugging information.