host: update System: Manage Host Keytab permission
    
    Since commit 5c0e7a5fb420377dcc06a956695afdcb35196444, a new extended
    operation to get a keytab is supposed to be used. This keytab
    setting/retrieval extended operation checks access rights of the bound
    DN to write to a virtual attribute 'ipaProtectedOperation;write_keys'.
    
    If the write isn't allowed, the operation is rejected and ipa-getkeytab
    tool falls back to an older code that generates the keytab on the client
    and forcibly sets to the LDAP entry. For the latter, a check is done to
    make sure the bound DN is allowed to write to 'krbPrincipalKey' attribute.
    
    This fallback should never happen for newer deployments. When enrollemnt
    operation is delegated to non-administrative user with the help of 'Host
    Enrollment' role, a host can be pre-created or created at enrollment
    time, if this non-administrative user has 'Host Administrators' role. In
    the latter case a system permission 'System: Manage Host Keytab' grants
    write access to 'krbPrincipalKey' attribute but lacks any access to the
    virtual attributes expected by the new extended operation.
    
    There is a second virtual attribute, 'ipaProtectedOperation;read_keys',
    that allows to retrieve existing keys for a host. However, during
    initial enrollment we do not allow to retrieve and reuse existing
    Kerberos key: while 'ipa-getkeytab -r' would give ability to retrieve
    the existing key, 'ipa-join' has no way to trigger that operation.
    Hence, permission 'System: Manage Host Keytab' will not grant the right
    to read the Kerberos key via extended operation used by 'ipa-getkeytab
    -r'. Such operation can be done later by utilizing 'ipa
    service/host-allow-retrieve-keytab' commands.
    
    Fix 'System: Manage Host Keytab' permission and extend a permission test
    to see that we do not fallback to the old extended operation.
    
    Fixes: https://pagure.io/freeipa/issue/9496
    
    Signed-off-by: Alexander Bokovoy <abokovoy@redhat.com>
    Reviewed-By: Rob Crittenden <rcritten@redhat.com>