Issue Description

I'm using the adafruit_wiznet5k library to run a wiznet5k_simpleserver on CircuitPython.
Here's the output from code.py:

code.py output:
Wiznet5k SimpleServer Test
Accepting connections on 192.168.11.171:50007
Connection accepted from ('0.0.0.0', 0), reading exactly 1024 bytes from client

This line appears even before any client has actually connected, which is incorrect behavior:

Connection accepted from ('0.0.0.0', 0)

Root Cause

After some digging, I believe the problem originates from the accept() method in adafruit_wiznet5k_socketpool.py. The method currently waits for any of these socket statuses:
adafruit_wiznet5k_socketpool.py

while self._status not in {
    wiznet5k.adafruit_wiznet5k.SNSR_SOCK_SYNRECV,
    wiznet5k.adafruit_wiznet5k.SNSR_SOCK_ESTABLISHED,
    wiznet5k.adafruit_wiznet5k.SNSR_SOCK_LISTEN,
}:

This condition causes accept() to return prematurely — including when the status is still SNSR_SOCK_LISTEN, which means no client has connected yet. As a result, the returned client socket is not actually connected, and has a peer address of ('0.0.0.0', 0).

Suggested Fix

The loop should exclude SNSR_SOCK_LISTEN and SNSR_SOCK_SYNRECV as valid conditions for returning.
The accept() method should only proceed when the socket status is SNSR_SOCK_ESTABLISHED (fully connected).

while self._status not in {
    wiznet5k.adafruit_wiznet5k.SNSR_SOCK_ESTABLISHED,
}:

This is important because the original WIZnet ioLibrary_Driver only considers a limited set of socket states in its typical control flow, as shown below:

getsockopt(sn, SO_STATUS, &status);
switch(status)
{
    case SOCK_ESTABLISHED:
    case SOCK_CLOSE_WAIT:
    case SOCK_INIT:
    case SOCK_CLOSED:
}

If the accept() function allows connections even when the socket is in SNSR_SOCK_SYNRECV state, it may incorrectly proceed in two problematic cases:

1. When the socket is not yet fully connected,
2. Or when another connection on a different port is in the SYNRECV state.

Both cases would falsely satisfy the condition and lead to unstable or incorrect behavior.

Additional Notes

#170 This issue also seems to be a symptom caused by the same problem.

This behavior breaks typical server flow since the server starts reading from a socket that is not actually connected. It also misleads developers during debugging and testing.

Would appreciate a review of the accept() logic in the socketpool adapter for Wiznet5k.

Thanks!