Implement CallHttp Polling Replay Logic

[hossam-nasr]

Resolves #284 . This PR:

• Adds the asynchronousPatternEnabled property to DurableHttpRequest, which is expected by the extension and enable polling logic
• Accepts the defaultHttpAsyncRequestSleepTimeMillseconds from the extension payload, which specifies the default period to wait between polling requests (Extension PR: Send Default Async HTTP Request Sleep Time in OOProc Payload azure-functions-durable-extension#2142)
• Introduces a new CompoundTask, the CallHttpWithPollingTask, which implements the logic for creating timers and new CallHttpActions when polling is enabled
• In CallHttp
  • If polling is enabled, a CallHttpWithPollingTask is returned, else a normal AtomicTask is returned
• In CallHttpWithPollingTask's trySetValue:
  • If the response code is 202 and the Location header is set, a new timer task and new call http task are created and added to the children
  • If any other response is given, it is set as the result of the entire task
  • If any child task fails, the entire compound task fails

Some questions/concerns:

• Do we need to worry about case sensitivity for HTTP headers? There are two places where we use headers: the Location header to determine whether to poll, and the Retry-After header to determine the timeout between polling requests. Currently they are case insensitive, but I'm not sure if we should be more lenient about this. As far as I could tell, extension code was also case insensitive, but I might be wrong.
• Should we make asynchronousPatternEnabled true by default? On the one hand, technically this isn't a new feature, but rather a bug in the previous implementation, and polling should've worked out of the box, so it makes sense to make it true by default (it is also true by default on the extension side), but on the other hand, if some customers were returning some 202 response code without intending to poll, they would now get unexpected behavior.
• Similarly, I also had a similar guard and error here that I used for the long timers, essentially blocking this feature unless replay schema V3 is being used. However, this is slightly different from the long timers in that it doesn't require any logical changes on the extension side. So, should I instead allow this to be used with replay schema < V3, and use some default value (perhaps the same default value used by the extension, bearing in mind that in the future, they could end up out of sync) for defaultHttpAsyncRequestSleepTimeMillseconds?

[davidmrdavid]

This looks great, but don't have a polling test yet, right?

[davidmrdavid]

It's looking good to me, we just need a test :-)

[davidmrdavid]

@hossam-nasr: once this PR is ready for a re-review, please request another review from me through the UI. Thanks!

[hossam-nasr]

I think this PR is ready for another review now. After discussing with @davidmrdavid, these were the decisions that we made that I updated this PR with:

• Header case-insensitivity: I missed a line in the extension code, which actually did make headers case-insensitive. I've updated this PR to also make the SDK treat headers case-insensitively.
• Polling is now enabled by default. Even if this is considered a breaking change, it's still fine because the next version of the SDK will be a major version, so it's best to err on the side of enabling functionality that should be enabled.
• The Schema V3 guard stayed in place. Even if we technically could still enable polling by specifying a default value for defaultHttpAsyncRequestSleepTimeMilliseconds if one is not provided by the extension, it's better to have the guard to encourage users to use the latest version of the extension.
• I've also added unit tests

[davidmrdavid]

tiny optimization. Other than that - 🚢 it.