s3: fix bug #6650, authentication at member servers when winbindd is not running

s3: fix bug #6650, authentication at member servers when winbindd is not running

Authentication of domain users on the member server fails when winbindd
is not running. This is because the is_trusted_domain() check  behaves
differently when winbindd is running and when it isn't:
Since wb_is_trusted_domain() calls wbcDomainInfo(), and this will also
give a result for our own domain, this succeeds for the member
server's own domain when winbindd is running. When winbindd is not
running, is_trusted_domain() checks (and possibly updates) the trustdom
cache, and this does the lsa_EnumTrustDom() rpc call to the DC which
does not return its own domain.

In case of winbindd not running, before 3.4, the domain part was _silently_
mapped to the workgroup in auth_util.c:make_user_info_map(),
which effectively did nothing in the member case.

But then the parameter "map untrusted to domain" was introduced
and the mapping was made to the workstation name instead of
the workgroup name by default unless "map untrusted to domain = yes".
(Commits
 d8c54fddda2dba3cbc5fc13e93431b152813892e,
 5cd4b7b7c03df6e896186d985b6858a06aa40b3f, and
 fbca26923915a70031f561b198cfe2cc0d9c3aa6)
This was ok as long as winbindd was running, but with winbindd not running,
these changes actually uncovered the above logic bug in the check.

So the correct check is to treat the workgroup as trusted / or known
in the member case. This is most easily achieved by not comparing the
domain name against get_global_sam_name() which is the host name unless
for a DC but against my_sam_name() which is the workgroup for a DC and for
a member, too. (These names are not very intuitive...)

I admit that this is a very long commit message for a one-liner, but this has
needed some tracking down, and I think the change deserves some justification.

Michael