Ticket #47410 - changelog db deadlocks with DNA and replication

https://fedorahosted.org/389/ticket/47410
Reviewed by: mreynolds (Thanks!)
Branch: 389-ds-base-1.2.11
Fix Description: The deadlock is caused by having an outer and an inner
transaction in one thread, and a replication reader in another thread.  The
outer transaction acquires a write lock on certain changelog db (cldb) pages
as a result of a previous nested transaction (e.g. a DNA shared config
area update).  The changelog reader in the cursor positioning operation
acquires read locks on certain other pages.  When another inner write
transaction occurs, it may attempt to acquire a write lock on a page held
by a read lock in the reader thread.  This will eventually fail because
the reader will not release its lock on the page until the outer transaction
releases the write lock on the page.
The solution is to change the way the deadlock detection thread works, to
use a different deadlock rejection policy.  When using DB_LOCK_MINWRITE
instead of the default DB_LOCK_YOUNGEST, the reader thread lock request is
rejected.  This means the code that positions the changelog cursor has to be
able to handle a DB_LOCK_DEADLOCK return.
Changing the deadlock rejection policy globally to DB_LOCK_MINWRITE has the
potential to cause any search to get a DB_LOCK_DEADLOCK from a db or cursor
get(), so this will need to be tested a great deal to make sure we can handle
all such cases.
Platforms tested: RHEL6 x86_64
Flag Day: no
Doc impact: no
(cherry picked from commit b573d80d9c3acc6dba1bd60bdf7bf3fe4f4168df)
(cherry picked from commit 2e1d6331a294378650bef9af8a5f24bd338ae01e)
(cherry picked from commit 1987727066e6248cac978139779193d0f56ff9ce)
Ticket 47385 - Disk Monitoring is not triggered as expected.

Bug Description: Is using large values for the threshold the faeture does not
                 work.

Fix Description: There was an overflow of a integer value uses to determine
                 if the server should enter the "shutdown mode".  Also removed
                 some unnecessary checks to see if disk space is continuing to drop.

https://fedorahosted.org/389/ticket/47385

Reviewed by: Noriko(Thanks!)
(cherry picked from commit 8486837842cd6779918520a17ca7c48441fe493b)
Ticket #47392 - ldbm errors when adding/modifying/deleting entries

https://fedorahosted.org/389/ticket/47392
Reviewed by: lkrispenz (Thanks!)
Branch: 389-ds-base-1.2.11
Fix Description: The problem is caused by cache consistency issues with the
RUV entry.  Before the txn starts, we grab a pointer to the RUV entry in
the cache.  When DNA (or any betxnpreop plugin) updates the database, it
will also grab a pointer to the cached RUV entry and modify it, out from
under the parent txn.  This can also cause the max CSN in the RUV to go
backwards - the nested txn will have a later CSN which will be
overwritten by the earlier CSN from the parent txn.
The fix is to move the ldbm_ruv_txn code inside the transaction loop after
the betxnpreop plugins have been run.  Also have to add modify_term inside
the retry logic to cancel the modify ruv txn stuff in order to retry.
The other part of the fix is to tell the code that updates the max CSN
in the RUV to skip changes that would cause the RUV to go backwards,
and return a code to the caller that tells the caller that the CSN is
already covered.  The code that updates the RUV for the txn will skip
the modify operations in that case.
Platforms tested: RHEL6 x86_64
Flag Day: no
Doc impact: no
(cherry picked from commit 9bf5ac83289dcadc922a628c652aebabc4725231)
Ticket #47428 - Memory leak in 389-ds-base 1.2.11.15

https://fedorahosted.org/389/ticket/47428
Reviewed by: rmeggins
Branch: 389-ds-base-1.2.11
Fix Description: Call ber_sockbuf_remove_io to remove our openldap io layer
from the connection c_sb and free the data associated with it.
Platforms tested: RHEL6 x86_64
Flag Day: no
Doc impact: no
(cherry picked from commit df93b03da12c22d18a4153105f687671e52efdd5)
(cherry picked from commit ed26da0722a23a50fb286e8bc57ec4fea8dde4a2)
(cherry picked from commit b18ee0b41fbcc901ed2a9b5c0431708e452a40c6)
Ticket 47427 - Overflow in nsslapd-disk-monitoring-threshold

Bug Description:  The threshold setting was being stored as an "int" instead
                  of a PRUint64.  Config setting validation was also incomplete.

Fix Description:  Changed the data type to PRUint64 from int, and improved the config
                  validation, and logging.

https://fedorahosted.org/389/ticket/47427

Reviewed by: richm & nhosoi(Thanks!!)
Ticket 47427 - Overflow in nsslapd-disk-monitoring-threshold

Bug Description:  The threshold setting was being stored as an "int" instead
                  of a PRUint64.  Config setting validation was also incomplete.

Fix Description:  Fix build warning caused by previous commit.

https://fedorahosted.org/389/ticket/47427
(cherry picked from commit 5724e02c7f30ef1130764c79b30edd04954663a7)
(cherry picked from commit 1b7135cc79114a41be147d6bac7f4353207623f1)
(cherry picked from commit b95142f08de7e3b7f66a395640709b80e7735bfd)