(This is a merge of http://go/wvgerrit/86383)
When Key Sessions were added to CryptoSession, the initialization of the
initial Key Session was placed at the end of the initialization of the
owning CryptoSession. That's all well and good except the block right
before that assumed that it was safe to abort initialization early in
order to swallow errors when setting up usage tables. As a result, if
anything caused usage table initialization to fail, it would leave the
CryptoSession without a Key Session, resulting in an inevitable segfault
further down the line.
There's no reason the Key Session can't be initialized first. This
change moves initialziation order around to avoid the bug.
Bug: 141021960
Test: CE CDM Unit Tests
Test: Android Unit Tests
Change-Id: Ic78005c831d2a24d7d6de22df54462b2bd7085f0
d7b17c469b