Fixed multiple issues where video stream resuming fails

[NicoleYarroch]

Fixes #1527

This PR is ready for review.

Risk

This PR makes no API changes.

Testing Plan

• I have verified that I have not introduced new warnings in this PR (or explain why below)
• I have run the unit tests with this PR
• I have tested this PR against Core and verified behavior (if applicable, if not applicable, explain why below).

Unit Tests

I added unit test for testing stopping the SDLStreamingVideoScaleManager, SDLStreamingAudioLifecycleManager and SDLH264VideoEncoder when the session between the accessory and device is closed.

Core Tests

Core version / branch / commit hash / module tested against: SYNC 3.4 BUILD 19353_DEVTEST_r133796
HMI name / version / branch / commit hash / module tested against: same as above

Summary

1. The streaming video lifecycle manager was not reset correctly on disconnect so sometimes an end video service request was sent incorrectly when a new session opened.
2. The pixel buffer pool in the SDLH264VideoEncoder class randomly invalidates itself when the device app is backgrounded. Handling was added to reset the pixel buffer pool when necessary, otherwise video frames will not be sent.
3. If the the response to the video start service comes after the app has been put in the background then the app now transitions to the suspended state instead of attempting to send video frames.
4. The streaming audio lifecycle manager now resets correctly on disconnect.

When testing you may run into this issue 1540 where no video is streamed by the CarWindow due to the video encoder failing when the app on the device is backgrounded. You will see error logs now when the pixelBuffer fails.

Changelog

Bug Fixes

• Fixed several issues where video stream resuming fails.

CLA

• I have signed the CLA

[NicoleYarroch]

@SatbirTanda I know you found additional issues with handling error messages from the security managers but can you also test this PR and see if it fixes some issues (r.e. #1527)?

[SatbirTanda]

Hi @NicoleYarroch, I was able to test this branch with my encrypted streaming app and I am still consistently seeing this issue: #1527

[NicoleYarroch]

@SatbirTanda Thanks for testing the PR. Can you see from the logs if any of these scenarios is occurring:

1. Video frames are being sent by the app but the head unit simply isn't showing the video.
2. Video frames are not being created because of an error with creating the video encoder or the pixel buffer.
3. The video start service NAKs or the video end service NAKs.

[SatbirTanda]

Yes I see 3) a NAK occurs on resumption - at which point the streaming state does not get set to STOPPED because an error is not handled properly #1527, it occurs specifically before the ssl handshake and needs to be handled in SDL iOS, looks like there was a TODO from 4 yrs ago:

sdl_ios/SmartDeviceLink/SDLProtocol.m

Line 725 in e948511

// TODO: (Joel F.)[2016-02-15] Should check for errors

Handling this error is a key in determining why NAKs occur in the first place. syncFrame is not being called to send any frames, its an infinite loop in sdl_processSecurityMessage

[NicoleYarroch]

Closing in favor of PR #1551