* Found on Android Things (N) running an embedded Cast receiver. 
* Cast receiver app version is 1.29.

Details:
---
This bug covers a number of rare case issues with the current media session implementation. Specifically: 

* When in ducking state and the focus is abandoned, we need to reset the is_ducking_ flag, or else it may start up ducked when a new focus is requested. This was fixed via https://chromium-review.googlesource.com/c/chromium/src/+/782539 but it should have some unit-tests to catch this condition.

* When in ducking state due to a LOSS_TRANSIENT_CAN_DUCK even and we receive a LOSS_TRANSIENT we are expected to suspend. This works partially today in that it suspends correctly, but it doesn't reset the is_ducking_ flag and as a result when resuming the session will start-up ducked (which is wrong). Note that it should not actually unduck the volume before suspending because this can cause a user-noticeable audio blip.

* When in suspend state due to a LOSS_TRANSIENT event and we receive a LOSS_TRANSIENT_CAN_DUCK event, we need to do two things - first duck the volume and then resume playback (doing it in reverse may cause a user-noticeable audio blip). This is not handled at all today afaik.

Pretty much all of these cases are rare boundary cases and hard to reproduce manually, so they should be reproduced via unit-tests instead.