Bug 799008

This bug is created as a clone of upstream ticket:
https://fedorahosted.org/sssd/ticket/1207

This ticket has been split from ticket #1202 to address the more complicated parts of this fix.

We added support for the Simple Paged Search in ticket #658 and SSSD 1.5.8. When we did so, we chose to default to always requesting paged searches for all requests. However, it turns out that RFC 2696 does not mandate that the LDAP server supports more than one paging search at a time on the same connection. Some LDAP servers (notably 389 DS 1.2.9 and older) allow only a single paged search to be in progress on a request at one time. This results in receiving an error from LDAP that the server refuses to perform the operation. Once ticket #1201 is fixed, this will result in offline operation (right now it's misbehaving as if it received zero results). We need to avoid both of these events.

RFC 2696 does specify that if the result size being returned is smaller than the requested page size that the paging control '''should''' be ignored. This would mitigate the problem, but it appears that 389 DS also chooses to not ignore the control in this case.

In general, we need to find ways to minimize our usage of the paging control where available. I propose the following changes:

1. Add a boolean option to {{{ldap_generic_search_send()}}} to specify whether to use the paging control (when available). -- done in Ticket #1202
1. Do not request the paging control when we expect a single-valued return from the request.
1. Always request the paging control for enumeration requests. -- done in Ticket #1202
1. Serialize paging requests by maintaining a queue of lookups requiring paging and allow only one to operate at a time.{{{[1]}}}
1. If it can be reasonably determined that replies will never exceed 500 entries, also omit the paging control{{{[2]}}}

{{{[1]}}}: This will likely introduce apparent performance issues when performing initgroups() requests, since they will no longer be able to run in parallel. We must always assume that the user may belong to many groups.

{{{[2]}}}: I'm not 100% sure about this one. It's possible for a server to manually set its page size smaller than 500, though I doubt very many would do so. On the other hand, I can't come up with any ideas offhand for lookups of greater than a single entry that could not therefore result in a potentially-infinite set of results. So this may be a moot point.