This bug is created as a clone of upstream ticket:
https://pagure.io/389-ds-base/issue/49765

#### Issue Description
This bug is a side effect of https://pagure.io/389-ds-base/issue/48184

With async operations on the same connection, the connection can be set several times in read_ready. This is done with connection_threadmain scheduling ns_handle_pr_read_ready (connection_make_readable_nolock).

When there is no more activity on the connection (no new req, timeout, closure..) and the server is listening to it (ns_handle_pr_read_ready), then if an async operation tries to schedule ns_handle_pr_read_ready it will hang (before completing the operation).

The consequence is one or more hanging operations on the connection with a stack like

    Thread 63 (Thread 0x7f794a711700 (LWP 28798)):
    #0  0x00007f7995e75c93 in select () from /lib64/libc.so.6
    #1  0x00007f7998e8046b in DS_Sleep (ticks=100) at 389-ds-base/ldap/servers/slapd/util.c:1086
    #2  0x0000000000438a6a in ns_connection_post_io_or_closing (conn=0x7f79550fc800) at 389-ds-base/ldap/servers/slapd/daemon.c:1835
    #3  0x0000000000427adc in connection_make_readable_nolock (conn=0x7f79550fc800) at 389-ds-base/ldap/servers/slapd/connection.c:1361                                                                                              
    #4  0x0000000000429e91 in connection_threadmain () at 389-ds-base/ldap/servers/slapd/connection.c:1724
    #5  0x00007f7996a0907b in _pt_root () from /lib64/libnspr4.so
    #6  0x00007f79965ab36d in start_thread () from /lib64/libpthread.so.0
    #7  0x00007f7995e7fb4f in clone () from /lib64/libc.so.6      

A way to mitigate the problem is to set a idletimeout

#### Package Version and Platform
1.3.7, 1.3.8 and master


#### Steps to reproduce

test case is not systematic.
On rapid machine, it hangs one out of ten

#### Actual results
Some operations are not completing (hanging)

#### Expected results
Should not hang