Consider optimisations of async configuration hotpaths for synchronously-provided results #18
Description
It seems reasonable that the delegates used to configure async MonkeyPolicy instances allow users to provide an async lambda. This permits users make async calls to consult some config source, for the enabled toggle, the injectionRate, or indeed what Exception, TResult, TimeSpan is going to be injected in fault scenarios. Currently the signatures we provide for such delegates are of the form Func<..., Task<bool>>, Func<..., Task<double>>, Func<..., Task<Exception>>, Func<..., Task<TResult>> etc.
That said, many (perhaps even a majority) usages might be sync. Simmy offers overloads taking constant values. Even for config-driven cases, it might be preferable for looking up the config to be a rapid in-memory check, with new values being pushed into that in-memory store by some other process (callback/monitor) when the underlying config source changes.
We want users to be able to include MonkeyPolicy in prod/whatever systems with minimal perf impact on executions, so want to optimise to minimise allocations and execution time.
Propose: Consider the use of ValueTask<>. Refs;