[Scanner] Consumer IO transport receives IO packets before binding to a connection, blocks updating of ACTIVE bitlist

It's observed (see the linked support ticket) that in a multi adapter setup, some times the scanner's ACTIVE bitlist is not updated properly and some devices are missing in this bitlist even if they are in a communication with the scanner and exchanging IO packets.

Root of the issue:
To establish connections on a scanner, the scanner will send a ForwardOpen requests to a list of adapters and then allocates and configures the required resources after receiving the ForwradOpen response from each adapter in the foolowing order:

1. Allocating and configuring the Producer IO transport 
2. Allocating and configuring the Consumer IO transport 
3. Binding athe associated Connection Configuration instance to those Consuming/Producing transports.

Once the consuming assembly is allocated, it will transition to ready state WAIT_FOR_DATA even if the binding is still not started. Receiving an IO packet in the high-prio thread, will trigger a one-shot update procedure of the ACTIVE bitlist which will fail since no Connection is associated with that transport yet.

Solution: Improve the IO transport state machine so that the transport will drop receiving IO packets before a connection is bound to that transport.