There are different expectations about how the pam_message array is
organized, details can be found in the pam_conv man page. E.g. sudo was
not able to handle the Linux-PAM style but expected the Solaris PAM
style. With this patch both styles should work as expected.

Resolves https://fedorahosted.org/sssd/ticket/2971

Reviewed-by: Pavel Březina <pbrezina@redhat.com>

We have a function sss_cli_check_socket which checks
socket in client code. The socket is reopened in case of some
issues e.g. responder terminated connections ...

We use syscall poll for checking status of socket.
It's not 100% reliable method because there is still
chance that responder will terminate socket after this check.

Here is a schema of sss_*_make_request functions:
    sss_cli_check_socket
    sss_cli_make_request_nochecks {
       sss_cli_send_req {
           poll
           send
       }
       sss_cli_recv_rep {
           poll
           read
       }
    }

The syscall pool does not return EPIPE directly but we convert
special revents from poll to EPIPE. As it was mentioned earlier,
checking of socket in the sss_cli_check_socket is not 100% reliable.
It can happen very rarely due to TOCTOU issue (Time of check to time of use)

We can return EPIPE from the sss_cli_make_request_nochecks function
in case of failure in poll in sss_cli_send_req. The send function
in sss_cli_send_req can also return EPIPE is responder close socket
in the same time. The send function can succeed in sss_cli_send_req
but it does not mean that responder read the message. It can happen
that timer for closing socket can be handled before reading a message.
Therefore there is a still a chance that we might return EPIPE in case
of failure in poll in sss_cli_recv_rep.

Therefore we need to reconnect to responder(sss_cli_check_socket)
in case of EPIPE returned from sss_cli_make_request_nochecks and
try to do the same request one more time.

Resolves:
https://fedorahosted.org/sssd/ticket/2626

Reviewed-by: Jakub Hrozek <jhrozek@redhat.com>

Patch for #2626 will be simpler with this small refactoring

Reviewed-by: Jakub Hrozek <jhrozek@redhat.com>

Resolves:
https://fedorahosted.org/sssd/ticket/2909

Reviewed-by: Lukáš Slebodník <lslebodn@redhat.com>
Reviewed-by: Noam Meltzer <tsnoam@gmail.com>

Resolves:
https://fedorahosted.org/sssd/ticket/2726

Reviewed-by: Michal Židek <mzidek@redhat.com>

If the memory cache was not initialized and there was a failure in
initialisation of memory cache context (e.g. memory cache file
does not exist) then mc_context had to be destroyed to release
resources.

However the count of active threads in sss_cli_mc_ctx is already higher
than zero because current thread is working wih the mc_context.
But this counter was zero-ed with memset in sss_nss_mc_destroy_ctx
due to issue with initialisation of memory cache.
Then we have to decrease counter of active thread in function
sss_nss_mc_get_ctx because initialisation of mc failed.
And the result of this decrement is underflow of counter.

Related to:
https://fedorahosted.org/sssd/ticket/2726

Reviewed-by: Michal Židek <mzidek@redhat.com>

There aren't any documented files in directory src/sss_client/sudo/

Reviewed-by: Jakub Hrozek <jhrozek@redhat.com>

setlocale needs some environment variables
to be set in order to work. These variables
are not present in some special cases. We
should not fail completely in these cases
but continue with the compatible C locale.

Resolves:
https://fedorahosted.org/sssd/ticket/2785

Reviewed-by: Michal Židek <mzidek@redhat.com>

Resolves https://fedorahosted.org/sssd/ticket/2803

Reviewed-by: Sumit Bose <sbose@redhat.com>