Fix memory leaks for IoT

[jkennington]

After removing an AWSIoTDataManager, the AWSIoTDataManager, AWSIoTMQTTClient, AWSURLSessionManager and other related entities were leaked.

This fixes a retain cycle between the AWSIoTMQTTClient where it held a strong reference to the associatedObject the AWSIoTDataManager which was holding a strong reference to the mqttClient. This makes the associatedObject reference weak.

If an AWSIoTDataManager was disconnected before the connectionAgeInSeconds exceeded the minimumConnectionTime the connectionAgeTimer was never invalidated and held a strong reference to the AWSIoTMQTTClient (e.g. self passed to the timer on creation of the timer). This fixes the issue by issuing an invalidate to the timer on the correct thread in the event the user requests a disconnect before reaching the minimumConnectionTime.

The AWSURLSessionManager creates and passes self to an NSURLSession but never invalidated the session to release the strong reference to self. AWSNetworking could be released but the AWSURLSessionManager leaked being held by the NSURLSession. This is fixed by having the AWSNetworking let the AWSURLSessionManager know it needs to invalidate the session when it is being released, as none of them should be needed after the AWSNetworking creating them is released.

[scb01]

I agree with this change.

[scb01]

Good catch. The connectionAgeTimer will self terminate once the max age has been reached, but if a disconnect is issued before then, it will continue to run and hold on to the object reference.

I think we can simplify this by just doing this after line 639. Thoughts?

     if (self.connectionAgeTimer != nil ) {
            [self.connectionAgeTimer invalidate];
            self.connectionAgeTimer = nil;
        }

[jkennington]

I believe we need to move the invalidate call because of the documentation below.

From https://developer.apple.com/documentation/foundation/nstimer/1415405-invalidate?language=objc

Special Considerations
You must send this message from the thread on which the timer was installed. If you send this message from another thread, the input source associated with the timer may not be removed from its run loop, which could prevent the thread from exiting properly.

[jkennington]

Updated PR at #1175