Do not wait for SSSD to become online if directory server is going
for shutdown. Since it is guaranteed that SSSD will not be able to
function with 389-ds offline, it makes no sense to continue a loop.

In case libsss_nss_idmap provides timeout-enabled NSS API, use it.
This solves a problem of too long queries to an NSS backend with
traditional POSIX NSS API. In case SSSD takes too long to respond
to a query, corresponding 389-ds thread running schema-compat plugin
would stuck waiting that response. It can lead to an exhaustion of
389-ds threads.

A refactored interface to NSS backends is introduced with this commit.
A backend API looks like an API an NSS plugin has to implement in glibc
but also allows to handle timeout-based requests internally.

If backend implements timeout-enabled calls, then
backend_nss_set_timeout() function can be used to modify a per-context
state. There is no need for a caller to know whether backend supports
timeout-enabled calls because either way these calls are synchronous
and backend choice is done at compile-time.

schema-compat plugin uses 10 seconds as its default timeout. One can
change it via 'slapi-nss-timeout' attribute in the plugin config entry.

SSSD exposes an extended NSS API via libsss_nss_idmap. This API allows
to query getpwnam()/getgrnam()/getgruid()/getpwuid()/getgrouplist()
information with a timeout per request. As result, an application has
possibility to cancel too long request.

This API also allows to ignore SSSD cache or invalidate it when
requesting certain information. slapi-nis needs this functionality when
invalidating own entries as result of changes done by other LDAP clients
in the areas which slapi-nis doesn't track directly.

For example, an update of ID override in the Default Trust View should
invalidate user or group entry for that AD object. Since retrieval of
the user/group information relies on SSSD, SSSD needs to be notified
that there is a change in ID override and evict the entry from its cache
as well.

Plug into a processing of LDAP add/delete/modify to see if an ID override entry
was added/deleted/updated. ID overrides aren't directly used to produce
map cache entries but when AD user or group is resolved, SSSD on IPA
master amends that information with ID Override from a Default Trust
View. Since nothing else would remove AD user or group entry from the map cache
on ID override change, handle their removal here.

Check if we have any nssswitch-generated entry in a map cache that
corresponds to this entry. Such entries would be evicted from the map
cache to allow their refresh.

Allow backends to inspect entries related to a map set

Entries may be related to a map set content but not used directly to
generate it. An example would be ID overrides in FreeIPA. An addition,
removal or change of an ID override in the Default Trust View should be
reflected by evicting an entry from the corresponding seti.

Let backends to handle exact logic. NIS backend does not support
exposing AD users so it provides set of dummy callbacks that always
return FALSE (entry is not related). Schema Compat backend, on other
hand, does track ID overrides in a Default Trust View in FreeIPA.

NIS doesn't need to handle ID overrides, it has to always skip related entries

Replacing the old link pointing to fedorahosted.org retirement page.

Signed-off-by: Stanislav Laznicka <slaznick@redhat.com>