[Fixes #2044] Implement an equivalent to AsyncTimeOutAttribute

[kichalla]

@yishaigalatzer @rynowak @GrabYourPitchforks @Tratcher

Please note:
This PR does not functional tests as HttpContext's Abort method doesn't work as expected(I get an OK response with no body) with in-memory host. I have manually verified timeout on IIS and Weblistener though.

@rynowak and I are planning to discuss with @GrabYourPitchforks to see if we could do something regarding this for in-memory scenarios. I wanted to get this PR out to get any initial comments.

Couple of interesting links regarding this:

• Crafting a Task.TimeoutAfter Method(http://blogs.msdn.com/b/pfxteam/archive/2011/11/10/10235834.aspx)
• http://stackoverflow.com/a/11191070/1184056

[Eilon]

< 0 ?

[kichalla]

yeah...my bad...I copy pasted this code from MVC 5 where we seem to honor Timeout.Infinite(whose value is -1)...not sure what is the realistic scenario where this makes sense..

[kichalla]

@Eilon, @rynowak, @GrabYourPitchforks: The latest commit has some major updates after some additional feedback from Levi and Ryan. Please take a look.

[Eilon]

Assuming this is @GrabYourPitchforks -approved, then

[yishaigalatzer]

This code doesn't address the basic scenario of cancelling operations not written by the user.

[kichalla]

@yishaigalatzer : Just FYI...following was the discussion that came up yesterday that drove the latest update's design change:

• Users writing code, which ideally should have been under a transaction, seem to not do it probably because they do not know that they have to do it or do not understand the implications of it.
  In these kind of scenarios, if we project the client disconnect token as the token that they should use, then the concern is about leaving data in possibly corrupted state as we are leaving this decision to the client...since a client cannot be trusted for this, users should be dependent only on the timeout token instead.

If we consider to honor the above mentioned scenario, not sure if we should be cancelling operations not written by the user...like even this could lead to corruption in state...

Just FYI...the HttpContext.RequestAborted is still present and has the client disconnected token which can be used...

/cc: @GrabYourPitchforks

[GrabYourPitchforks]

FYI, per our discussion Friday afternoon I believe this feature was killed.

[Eilon]

indeed. We'll bring it back in a future update.

[kichalla]

Sure..closing this PR now..thanks..

[Pzixel]

So currently there is not way to provide set timeout for async request?

[Eilon]

@Pzixel there are no current plans to have this built-in. You can add your thoughts to the original issue, #2044. There are also some additional potentially related thoughts and notes in #5239.