NO-JIRA: [Python] IO: Add ENETUNREACH to the list of tolerated errors

[Jmennius]

...which will enable reconnection logic to act in this case.
ENETUNREACH can happen when target network is unreachable for example
when the network stack was not fully initialized yet or when a network
is not connected temporarily, etc.
This makes ENETUNREACH handled just like EHOSTUNREACH
(which is for some reason indicated with EINPROGRESS in this part of the code).

[codecov-commenter]

Codecov Report

Merging #365 (bb27336) into main (a920192) will increase coverage by 20.11%.
The diff coverage is n/a.

❗ Current head bb27336 differs from pull request most recent head ba58d8c. Consider uploading reports for the commit ba58d8c to get more accurate results

@@             Coverage Diff             @@
##             main     #365       +/-   ##
===========================================
+ Coverage   68.24%   88.36%   +20.11%     
===========================================
  Files         367       47      -320     
  Lines       73285     2397    -70888     
===========================================
- Hits        50011     2118    -47893     
+ Misses      23274      279    -22995     

Impacted Files	Coverage Δ
python/proton/_io.py
cpp/examples/encode_decode.cpp
cpp/examples/broker.cpp
...est_PROTON_2116_blocking_connection_object_leak.py
cpp/src/transport.cpp
c/src/sasl/default_sasl.c
cpp/src/connection_options.cpp
c/src/core/error.c
cpp/src/container.cpp
c/examples/raw_connect.c
... and 310 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update a920192...ba58d8c. Read the comment docs.

[astitcher]

Thanks for looking at and debugging the issue you found. I'm pretty sure this isn't the correct place for the fix (even if it was the easiest place to fix your issue).

In future it really helps us to raise an issue connected with fixes for tracking purposes also to understand the environment of the issue - was this under Windows/MacOS or Linux for example as the errno behaviour can vary between the platforms.
Certainly your comment about EHOSTUNREACH is not true for Linux, and that seems to me to be a much more important connect failure case than ENETUNREACH.

[astitcher]

I'm pretty sure this change doesn't make sense at this point in the code:
The very low level connect is only making sure that a connect on a nonblocking socket worked - the only "non errors" on a non blocking socket are the ones listed - they indicate that the operation is in progress.
ENETUNREACH indicates that the connect operation failed (at this low level). Any retries because of this kind of failure need to be handled at a higher level.

[Jmennius]

Thanks for looking at and debugging the issue you found. I'm pretty sure this isn't the correct place for the fix (even if it was the easiest place to fix your issue).

In future it really helps us to raise an issue connected with fixes for tracking purposes also to understand the environment of the issue - was this under Windows/MacOS or Linux for example as the errno behaviour can vary between the platforms. Certainly your comment about EHOSTUNREACH is not true for Linux, and that seems to me to be a much more important connect failure case than ENETUNREACH.

Sure, thanks for the feedback! Should I open an issue (at this point)?
This was on Linux. I am pretty sure that it behaves like I've described it, which is indeed unexpected...

[astitcher]

Sure, thanks for the feedback! Should I open an issue (at this point)?

I think this deserves an issue - although there may already be an issue about reconnect not correctly working if the failure is the initial connect operation.

This was on Linux. I am pretty sure that it behaves like I've described it, which is indeed unexpected...

It could well be that in the case of EHOSTUNREACH this doesn't get discovered immediately which makes it EINPROGRESS, but eventually fails when the target router sends back the unreachable ICMP packet.

[Jmennius]

Opened PROTON-2528.