WinInetRequestWrapper::cancel() should remove status callback

[HIROSN]

Describe your environment.
Microsoft Edge 80.0.326.0
SDK version 3.2.176.1

Steps to reproduce.
No repro steps.
This is a Watson bug: Bug 23052293: [Watson Failure] caused by BAD_INSTRUCTION_PTR_c0000005_oneds.dll!Unloaded

What is the expected behavior?
Browser shutdown without issues.

What is the actual behavior?
We unload our DLL after flush and tear down log manager. Occasionally a callback to WinInetRequestWrapper::winInetCallback is made in the unloaded DLL.

Additional context.
Thanks to @bliptec, here is a proposed fix.

    void cancel()
    {
        if (m_hWinInetRequest != nullptr)
        {
            ::InternetSetStatusCallback(m_hWinInetRequest, nullptr);
            ::InternetCloseHandle(m_hWinInetRequest);
            // don't wait for request callback
        }
    }

[maxgolov]

We need to carefully review this solution. I see some drawbacks here: the cancel method has actually been designed as async. Force-closing the internet handle is expected to trigger an "aborted" notification to be processed inside the status callback.

We can probably consider adding a new parameter to this, e.g.
void cancel(bool force = false)

And implement your proposed behavior only for the shutdown scenario. That way the cancellation routine becomes synchronous. What we are essentially losing is the ability to tell whether the request has been processed with 200 OK, or if it's been prematurely aborted. Force-closing might result in somewhat more data duplication at shutdown. Because we'd be essentially ignoring any status notification on a force-closed handle, even if the request has been already complete with 200 OK. Probably in range of under 1-2%....

The other drawback that the objects are "self-destructing", and the graceful request clean-up is done from the callback. By removing callback we'd be causing a mem-leak on shutdown. We need to review how to provide either async or sync callback gracefully, so that we try to process a status within given timeout window, if possible, and we always 100% clean up the resources irrespective of whether we got the status or not.

[maxgolov]

I'd like to work on a better solution as part of #161 .. I see too many risks with implementing what is being proposed here.

[maxgolov]

Reforecast to [Mn] due to higher priority Azure work.

[maxgolov]

I implemented what I believe is the right solution in #266