Fix memory leak when serving static content

[jeffthiele]

Prerequisites

• I have written a descriptive pull-request title
• I have verified that there are no overlapping pull-requests open
• I have verified that I am following the Nancy code style guidelines
• I have provided test coverage for my change (where applicable)

Description

Added calls to dispose the CancellationTokenSource when the engine returns static content and on errors. Potentially fixes the memory leaks described in #2605 without reverting the fix in #2150

[dnfclas]

All CLA requirements met.

[cloudhunter89]

Does the TaskCompletionSource use or reference the Cancellation Token? I don't quite understand how the
try ... finally { cts.Dispose() } is any different than

cts.Dispose(); 
return tsc.Task;

This isn't dependent on the asynchronous execution of anything, unlike the lifeCycleTask below, is it?

[jeffthiele]

The only difference is that try{...}finally { cts.Dispose();} will still dispose of the CancellationTokenSource whether an exception occurs on the intervening lines or not.

[cloudhunter89]

Ah, going for the equivalent behavior of declaring a using block inside this scope, and there is some possibility of an exception setting the result or the response. That makes more sense to me.

[cloudhunter89]

In theory each of the individual try...finally... could be replaced with separate using (cts) {...} right? (Just working out some personal edification here)

[jeffthiele]

In these cases, yes, I think it would be functionally the same. Personally, I like being more explicit that we're only disposing of the item here since the typical use of using also instantiates the object and could potentially be misinterpreted by others looking at the code.