Don't split req_ctx with ATR payload

The codnition for flushing a req_ctx on UART idle is fixed to flush only
if
1) There has been no new data since last check, and
2) There are no req_ctx currently pending to be transmitted to USB, and
3) We did NOT just got a reset and waiting for ATR

I saw an ATR split in two different req_ctx prior, presumably flush
decided to send req_ctx after ATR but got a new character just before
sent).  If we did get a RESET, let original logic decide to send the
req_ctx -- presumably when ATR data is fully received.

0 files changed, 0 insertions, 0 deletions