Implements RequestAdditionalTime for use in pending states

[cerebrate]

Implements the equivalent of ServiceBase.RequestAdditionalTime for services which are slow to transition between states.

(It does this as a method of Win32ServiceHost, which requires keeping a reference to Win32ServiceHost around where the service implementation can call it; that's not the cleanest possible way of doing it, but adding it to IWin32Service/IPausableWin32Service would be a breaking change.)

[turowicz]

Please merge this @dasMulli

[dasMulli]

This should be implemented in an IWin32ServiceStateMachine subclass which is responsible for calling the ServiceStatusReportCallback callback with appropriate commands.

Exposing the control over something that the state machine is supposed to handle feels too hacky.

Right now, this can already be implemented in user code by e.g. copying SimpleServiceStateMachine to user code and adding timeout handling logic there.

There are a few things that could be done here:

1. Add a new interface for services that has additional callback methods on the Start/Stop/* methods - IWin32Service2 or ITimeoutAwareWin32Service etc.
2. Add a new extending interface that can be checked for at run-time, e.g. ITimeoutAwareWin32Service { TimeoutCallback { set; } } that requires a setter for a timeout callback,
3. • Add an state machine that already knows how to expand the timeout while waiting for user code.

I'm actually quite interested in doing (3) and adding something like an IAsyncWin32Service with async start/stop/* methods instead. The calling state machine would then be able to do a timeout-based wait on the task - requesting additional time for each wait.

[turowicz]

@dasMulli could you release an alpha package with above PR at least?

[dasMulli]

@turowicz you could download the nupkgs from https://ci.appveyor.com/project/dasMulli/dotnet-win32-service/build/52-master-fimpgsov/artifacts

[dasMulli]

@turowicz I'd be interested to know if your problem is mainly requiring additional time for the stop operation or more in general? the default timeout could also be made configurable for all operations of the service host..

[turowicz]

Hey yes I need to protect my service from exiting too early. The time it requires to quit is variable, depending on which task it's currently processing.

[turowicz]

... but that said I think I will just upgrade to dotnet core 2.1-rc1 and use ServiceBase.

[cerebrate]

@dasMulli Well, (1) was the first approach that occurred to me, but thinking about it from a library perspective rather than one specific to my usage, it seemed to me that this would lead to a rather inelegant profusion of IVariantWin32Service interfaces and associated state machines.

(For example, another thing I'm working on - and would like to contribute back - is an implementation of the Shutdown and Power Event service functionalities. Even if we assume that for most purposes Shutdown is a de facto power event, my specific requirement is for a service that can also request more time - it has a variable length shutdown - and pause/continue, so short of turning my specific requirements into a new interface/state machine and leaving it at that, we end up with IPausableWin32Service, IPowerAwareWin32Service, ITimeoutAwareWin32Service, and all the various combinations of same to let users have the features they want. Still thinking about the best approach here.)

And so I wanted something that could operate with any existing and potential future state machine. It is uncomfortably hacky, though, so if you'll leave this pull request open for a couple of days, I'll look into refactoring it to something more along the lines of (2).