binder: Inbound.java reassembly logic needlessly handles out-of-order transactions, fails to handle silently dropped ones. #12747

Inbound has code to handle Binder transactions delivered out-of-order, something that can't happen (see IBinder#FLAG_ONEWAY). At the same time, it fails to handle the rare case where transactions are silently dropped.

We should simplify the message reassembly code and fail fast on gaps instead of waiting forever for a transaction that will never come. If an incoming transaction index doesn't have the next expected value, immediately close the stream (with DATA_LOSS? UNAVAILABLE?). This avoids a hang, allowing callers to retry sooner.