Bug #30932 slave_net_timeout for connect() to master is not optimal.

Description:
Connections to master from slave use slave_net_timeout as connect() timeout. 
There're multiple issues with it:

a) Default value is 3600, so connect() will be terminated by OS rather than MySQL
b) Reducing slave_net_timeout to reasonable amount for connect() (like 10s) would cause disconnects in case of idle replication, as well as log rotation (see Bug#20435)

As there is no way to fail fast with connects (unlike in client library), it seems to be buggy implementation of replication networking. 

How to repeat:
SLAVE START;

Suggested fix:
decouple connect timeout from network timeout, make it settable properly or at least set to reasonable value.

With fixes for bug#20435 introducing a new heartbeat feature `slave_net_timeout'
can be set to a small values e.g the same suggested 10 seconds.
The heartbeat replication event - to be sent in master's idling time - resets `slave_net_timeout'. Provided that the heartbeat period would be set to a value
less that `slave_net_timeout' there is a very slim chance for the latter to elapse and force reconnecting.

This is fixed by the fix for BUG#20435:

> a) Default value is 3600, so connect() will be terminated by OS
>    rather than MySQL

With heartbeats enabled, there will be no termination of connect().

> b) Reducing slave_net_timeout to reasonable amount for connect()
>    (like 10s) would cause disconnects in case of idle replication, as
>    well as log rotation (see Bug#20435)

With heartbeats enabled, there will be no idle replication.

Documented fix in mysql-5.1.22-ndb-6.3.4 changelog; closed.

This is generic bug, not related to NDB - is it going to be added to mainstream versions?

Domas, yes it will appear in 6.0.

Also documented for 6.0.4 release - see also Bug #20435.

Still in 5.7.21 in production.