If the IpSecTransform is being manipulated in
multiple threads, there is a race between the
clearing of the resource id (setting it to
INVALID_RESOURCE_ID and making binder calls
with it. This wasn't a significant problem before
becasue the only side effect was that it could
occasionally cause an IAE instead of an ISE when
the caller was doing something weird. Unfortunately
the exception type now matters because it is being
relied upon to provide a callback rather than a
throw in the event of an error. Accordingly reads of
mResourceId have to be synchronized against the
the possibility of close() of that resourceId to
ensure that the right exception is thrown on the
service side of the binder.
Bug: 336897538
Test: atest CtsNetTestCases:IpSecManagerTest
Change-Id: I21c893034efa7f322ae2aa81d6c7e00dc9ef8d2f
98b708d5a2