Fix #2484 - clear m_fill on flush exception

[tchaloupka]

Well it's a workaround for this particular issue.

Problem is that in StreamOutputRange destructor flush() is called to make sure that data has been written.
But when exception is thrown in it, destructor won't cleanup what'll normally be cleaned up and so the leak.

I've fixed it by resetting m_fill in a flush itself but it works only when written data are bigger than the internal buffer so flush is called and fails before the destructor.
For this case to work I've added manual flush() to doWriteJsonBody() so it's called before the destructor.

But there are much more places this can cause random problems and I'm not sure what would be the best approach for this. But throwing exceptions in destructors or allocating in them can easilly lead to InvalidMemoryOperation when called from GC (which is not this case).

[tchaloupka]

One way we can workaround this for all StreamOutputRange usages is with something like this:

~this()
{
    static if (hasElaborateDestructor!OutputStream) scope(failure) destroy(m_stream);
    flush();
}

[tchaloupka]

I've changed the patch of StreamOutputRange cleanup to work in all cases.
For reference I've also created https://issues.dlang.org/show_bug.cgi?id=21322

[s-ludwig]

The workaround sounds good for now, I don't really see what else could be done here, apart from just asserting the the range has been flushed. But this range was meant to be supported by RAII, so that would be quite unfortunate.

We can drop the scope (exit) m_fill = 0; with the scope (failure) workaround, though, right? Semantically it seems nicer in the sense that it could allow to retry the transfer (although whether the outcome is well defined, obviously depends on the underlying stream implementation).

[tchaloupka]

Ok, I've reverted the m_fill reset in flush(). Only problem with that is that when exception is thrown in flush() then it would be thrown again in the destructor itself in this case.

[s-ludwig]

True, that may be unexpected. A flag that skips the destructor flush whenever the last operation was not successful looks like it would result in the expected behavior. But I'd open a quick separate PR for that, to first fix the important part here.

[s-ludwig]

I've opened the follow-up PR: #2489