Allow reuse of Apple's NSURLSessions

[lawrencewuskyboxlabs]

The current implementation of AppleHttpProvider will spin up a new NSURLSession with each call that is performed. This somewhat goes against Apple's recommended practice of reusing the sessions when possible and is leading to out of memory issues in cases where a high number of concurrent calls are active, along with possibly another memory leak due to the sessions not being manually invalidated. These changes rework the Provider and the SessionDelegate to allow the same session to be used for calls that share the same timeout period, as this is the only difference in the currently-created session configs.

• A new AppleHttpSessionManager has been introduced which largely replaces the functionality provided by the old http_task_apple. Rather than individual http_tasks being created, there is only one Manager which is responsible for creating sessions, creating and running NSURLSessionTasks on the appropriate sessions, and closing sessions when all their tasks are completed. Sessions are identified by their timeout period, and each session also has a corresponding map of AppleHttpTaskContexts keyed by NSUInteger task identifiers. This is to keep track of the HCCallHandle and XAsyncBlock that should be used for each task, since originally the http_task had this info on an individual basis.
• The AppleHttpProvider owns the Manager through a shared pointer and is essentially a wrapper around the Manager, due to the required opaqueness of the NSObjects the Manager has to use. The shared pointer is to allow weak pointers to be safely made.
• Each session still has its own SessionDelegate, but since there can now be multiple tasks running, the Delegate also maintains its own map of TaskContexts keyed by task identifiers. It needs to track the call handle and, for reporting purposes, the expected download size on a per-task basis. The call handle can be given by the Manager after a task is created since the Manager is also responsible for starting the task. The download size can be cached upon the first response the task receives.
• The completion handler block make use of the aforementioned weak pointers to the Manager.
• The old _dataToDownload in the Delegate, which was only used to report the amount of bytes downloaded so far, is deemed unnecessary because the call handle's responseBodyBytes should match it after it's written to.
• With the removal of http_tasks, the call handle no longer has context set by the Provider. This is considered to prevent another possible memory leak in the old implementation, where the release of the http_task in the Provider meant it was up to the call handle to clean up the http_task. Apple and Android are the only platforms in libhttp that have the context set so this also brings Apple more in line with the majority.

[alexsc-mojang]

!extreme nit
prefer "self"

[alexsc-mojang]

I'm confused why the key for this map is timeoutInSeconds, couldn't this collide, like, a lot?

[lawrencewuskyboxlabs]

This is because with the original implementation of each call causing a session to be made, the only differences in those sessions were:

• how the delegate handled events (writing to a particular call's response body, triggering some completion handler, etc.)
• the timeout the session would allow for a task running on it

The delegate's handling is pretty self-contained and the session itself doesn't really interact with its details. However the timeout is something that is defined in the session's config and can't be changed after the session is created. So I figured this would be the best way to identify sessions and choose which ones can be reused among calls; if a session already exists with the same timeout, then the call's corresponding task can run on it and let the delegate handle the per-task specifics.