trust-fetch-domains: use custom krb5.conf overlay for all trust operations
    
    Operations in FIPS mode make impossible use of NTLMSSP when
    authenticating to trusted Active Directory domain controllers because
    RC4 cipher is not allowed. Instead, Kerberos authentication have to be
    used. We switched to enforce Kerberos authentication when communicating
    with trusted domains' domain controllers everywhere.
    
    Kerberos library uses system wide configuration which in IPA defaults to
    resolving location of KDCs via DNS SRV records. Once trust is
    established, SSSD will populate a list of closest DCs and provide them
    through the KDC locator plugin. But at the time the trust is established
    performing DNS SRV-based discovery of Kerberos KDCs might fail due to
    multiple reasons. It might also succeed but point to a DC that doesn't
    know about the account we have to use to establish trust.
    
    One edge case is when DNS SRV record points to an unreachable DC,
    whether due to a firewall or a network topology limitations. In such
    case an administrator would pass --server <server> option to
    'ipa trust-add' or 'ipa trust-fetch-domains' commands.
    
    'ipa trust-fetch-domains' runs a helper via oddjobd. This helper was
    already modified to support --server option and generated custom
    krb5.conf overlay to pin to a specific AD DC. However, this
    configuration was removed as soon as we finished talking to AD DCs.
    
    With switch to always use Kebreros to authenticate in retrieval of the
    topology information, we have to use the overlay everywhere as well.
    
    Convert the code that generated the overlay file into a context that
    generates the overlay and sets environment. Reuse it in other
    trust-related places where this matters.
    
    Oddjob helper runs as root and can write to /run/ipa for the krb5.conf
    overlay.
    
    Server side of 'ipa trust-add' code calls into ipaserver/dcerpc.py and
    runs under ipaapi so can only write to /tmp.  Since it is a part of the
    Apache instance, it uses private /tmp mounted on tmpfs.
    
    Fixes: https://pagure.io/freeipa/issue/8664
    Related: https://pagure.io/freeipa/issue/8655
    Signed-off-by: Alexander Bokovoy <abokovoy@redhat.com>
    Reviewed-By: Christian Heimes <cheimes@redhat.com>
    Reviewed-By: Rob Crittenden <rcritten@redhat.com>
    Reviewed-By: Christian Heimes <cheimes@redhat.com>
    Reviewed-By: Rob Crittenden <rcritten@redhat.com>