[Pcsclite-muscle] CCID: Reduce status change latency by using the status from RDR_to_PC_NotifySlotChange?

[Ran Benita]

For readers which support it, the CCID driver listens for
RDR_to_PC_NotifySlotChange notifications on the interrupt endpoint. This
replaces the need for polling. When a RDR_to_PC_NotifySlotChange notification
is received, the CCID driver then issues a PC_to_RDR_GetSlotStatus to get the
new status and notify the application.

However, the RDR_to_PC_NotifySlotChange already contains the new status of the
slot(s). If the CCID driver were to use it, it could skip the
PC_to_RDR_GetSlotStatus roundtrip, thereby removing the 10-20ms latency it
adds (by my measurement with a couple of readers) before the application gets
the status change. IMO, 10-20ms latency for SCardGetStatusChange, while not a
lot, is not insignificant.

What are your opinion on this idea? As a proof of concept, I modified
`InterruptRead` to return the new status to `IFDHPolling`, which stashes it in
the `CcidSlots`; then `IFDHICCPresence` uses this status, if it is set,
instead of calling `CmdGetSlotStatus`. This seems to work from rudimentary
testing, although there is some business with `bPowerFlags` that I haven't
gotten to the bottom of. Hopefully someone more familiar with the code can do
it properly, if the idea is sound.

Ran