Split runtime from static configuration and use it for request context.

[albu-diku]

The purpose of this change is twofold: first, firm up the notion of a runtime configuration as distinct from the static configuration loaded on disk and second, with this separation enforced, to prepare for further uses of the runtime side.

Note that the need to do this originated with the needs of templates - consider that a user may need a specific locale to be reflected in the ui for example. An observation was made that we already attach runtime properties to configuration (see mig_server_id, the logger) and must be additional work in various places to sidestep those additions.

Opt to do this by making an object which internally keeps a reference
to an underlying configuration object, proxies attribute access to and can thus be used as a substitute in any call stack of logic. Name this RuntimeConfiguration.

Use the split to add a the notion of a context. This idea was independently arrived at by myself and others on the team. With the support in hand, rework email sending to be context aware - that is, one can simply make use of send_email as before. Internally it will check whether sending was previously done (by consulting the context) and skip any construction steps if so.

As a result of this small change, we become able to centrally intercept email sending without threading arguments through multiple levels of the call stack of logic code purely to override email sending and we can do useful general enforcement.

Add a means for tests to check the the number of emails sent and whether an email was sent to a particular recipient. By default, enforce disallowing unexpected outgoing emails. This has the effect of nudging test writers to account for emails as a covered side effect of the logic being exercised. For cases where the email send is not relevant t, there is an escape hatch.

[albu-diku]

@rasmunk this is what came of our discussion of the concept the other day :)

[rasmunk]

One note, I think in general when then underlying receiving implementation starts to utilise the RuntimeConfiguration specific functions such as context_get that the caller should be aware that it is no expecting a standard configuration anyone. So I would think that we would call it runtime_configuration here instead. Especially since the get_configuration_object in the PR allows for the raw instance to be returned instead at this point which could cause a mixup if one was not aware that a different configuration type was expected here.

[albu-diku]

Yeah - that raw argument is not one I'd expect anybody to use normally, and given your mentioning it I'm almost tempted to give it a leading undersco.re It was purely done so that - necessity of the way this is put together currently - the test support code can still grab a raw configuration and wrap it itself.

As for the the naming, yeah I thought abut that too. My instinct was to do that but I chose not to with the feeling it introduces too much inconsistency wrt the rest of the tree at present. See how that argument sits with you - one thing we could to to make this clear is add an assert here to make clear it must be a runtime configuration, and perhaps that threads the needle a little more?

[rasmunk]

A leading underscore on raw and a subsequent instance assertion on the configuration being passed as a transition state is also fine by me . Then when we get the complete split between runtime and static configuration it is reasonable to expect that aconfiguration argument would be a runtime instance in all migrid-sync's functions, since we would call the static one directly when needed.