IFP: Don't pre-allocate the amount of entries requested
    
    By allocating the number of entries when actually copying the list we
    can avoid situations where users request an enourmous amount of results
    but the number of results got from the backend are just a few.
    
    With this new approach we end up allocating the whole list more
    frequently but we avoid not returning valid results because the
    requested number of enties is too big (note that if the amount of
    results is too big as well, there's nothing much we can do).
    
    A simple reproducer for this issue can be the really extreme call:
    $ dbus-send --system --print-reply  --dest=org.freedesktop.sssd.infopipe \
      /org/freedesktop/sssd/infopipe/Users \
      org.freedesktop.sssd.infopipe.Users.ListByName string:"*" uint32:"-1"
    
    The example pasted above would try to allocate an array of MAX_UINT32
    size, which would fail directly.
    
    Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
    Reviewed-by: Pavel Březina <pbrezina@redhat.com>