[BUG] `salt-call --local` stuck if hostname does not resolve to IPv4

Description

In most setups, a DNS and/or /etc/hosts entry containing the machine hostname/FQDN (matching /etc/hostname) exists:

192.168.1.1 example.com example
fd80::1 example.com example

During a salt-call --local state.* operation, salt-call tries to resolve the machine name:

....
uname({sysname="Linux", nodename="orbit20.infra.opensuse.org", ...}) = 0
....
setsockopt(4, SOL_IP, IP_RECVERR, [1], 4) = 0
connect(4, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.144.53.54")}, 16) = 0
poll([{fd=4, events=POLLOUT}], 1, 0)    = 1 ([{fd=4, revents=POLLOUT}])
sendto(4, "\10\371\1\0\0\1\0\0\0\0\0\0\7orbit20\5infra\10opensuse\3org\0\0\1\0\1", 44, MSG_NOSIGNAL, NULL, 0) = 44

If the IPv4 entry is removed from /etc/hosts, and no nameservers from /etc/resolv.conf resolve it, the DNS resolution will get stuck until it runs in a timeout. Only after this timeout, the salt-call operation will proceed at the expected pace.

The non-strace output makes it look like it is getting stuck at the zfs grains module, though I presume that is simply the unfavorable last module in the alphabet before some other logic happens, as I could not find any networking code in the zfs utils.

orbit20 # salt-call -ldebug --local state.test role.hypervisor.standalone
[DEBUG   ] Reading configuration from /etc/salt/minion
[DEBUG   ] Including configuration from '/etc/salt/minion.d/yast-configuration-management.conf'
[DEBUG   ] Reading configuration from /etc/salt/minion.d/yast-configuration-management.conf
[DEBUG   ] Including configuration from '/etc/salt/minion.d/yast_custom.conf'
[DEBUG   ] Reading configuration from /etc/salt/minion.d/yast_custom.conf
[DEBUG   ] Using cached minion ID from /etc/salt/minion_id: booorbit20.infra.opensuse.org
[WARNING ] Insecure logging configuration detected! Sensitive data may be logged.
[DEBUG   ] Configuration file path: /etc/salt/minion
[DEBUG   ] Grains refresh requested. Refreshing grains.
[DEBUG   ] Reading configuration from /etc/salt/minion
[DEBUG   ] Including configuration from '/etc/salt/minion.d/yast-configuration-management.conf'
[DEBUG   ] Reading configuration from /etc/salt/minion.d/yast-configuration-management.conf
[DEBUG   ] Including configuration from '/etc/salt/minion.d/yast_custom.conf'
[DEBUG   ] Reading configuration from /etc/salt/minion.d/yast_custom.conf
[DEBUG   ] The functions from module 'core' are being loaded by dir() on the loaded module
[DEBUG   ] The functions from module 'disks' are being loaded by dir() on the loaded module
[DEBUG   ] The functions from module 'extra' are being loaded by dir() on the loaded module
[DEBUG   ] The functions from module 'lvm' are being loaded by dir() on the loaded module
[DEBUG   ] The functions from module 'mdadm' are being loaded by dir() on the loaded module
[DEBUG   ] The functions from module 'minion_process' are being loaded by dir() on the loaded module
[DEBUG   ] The functions from module 'opts' are being loaded by dir() on the loaded module
[DEBUG   ] Override  __utils__: <module 'salt.loaded.int.grains.zfs' from '/usr/lib/python3.6/site-packages/salt/grains/zfs.py'>
[DEBUG   ] The functions from module 'zfs' are being loaded by dir() on the loaded module
^C^C^C

Setup

• on-prem machine
• VM (Virtualbox, KVM, etc. please specify)
• VM running on a cloud service, please be explicit and add details
• container (Kubernetes, Docker, containerd, etc. please specify)
• or a combination, please be explicit
• jails if it is FreeBSD
• classic packaging
• onedir packaging
• used bootstrap to install

No test data/pillar needed. An empty /srv/salt and /srv/pillar will do.

Steps to Reproduce the behavior

1. Create empty salt file root and pillar directories or populate them with any data
2. Ensure the entry in /etc/hostname does not exist along with any IPv4 address in /etc/hosts
3. Run salt-call -ldebug state.test
4. Notice the operation hanging at the zfs grains module

Expected behavior

I expect a --local operation to not perform any network operations unless instructed by user provided state code. However if network operation is required, it should not hang if the machine hostname/FQDN do not resolve using IPv4.

Screenshots

n/a

Versions Report

Salt Version:
          Salt: 3006.0

Python Version:
        Python: 3.6.15 (default, Sep 23 2021, 15:41:43) [GCC]

Dependency Versions:
          cffi: 1.13.2
      cherrypy: Not Installed
      dateutil: Not Installed
     docker-py: Not Installed
         gitdb: Not Installed
     gitpython: Not Installed
        Jinja2: 2.10.1
       libgit2: Not Installed
  looseversion: 1.0.2
      M2Crypto: 0.38.0
          Mako: Not Installed
       msgpack: 0.5.6
  msgpack-pure: Not Installed
  mysql-python: Not Installed
     packaging: 20.3
     pycparser: 2.17
      pycrypto: Not Installed
  pycryptodome: Not Installed
        pygit2: Not Installed
  python-gnupg: Not Installed
        PyYAML: 5.4.1
         PyZMQ: 17.1.2
        relenv: Not Installed
         smmap: Not Installed
       timelib: Not Installed
       Tornado: 4.5.3
           ZMQ: 4.2.3

System Versions:
          dist: opensuse-leap 15.5
        locale: UTF-8
       machine: x86_64
       release: 5.14.21-150500.55.19-default
        system: Linux
       version: openSUSE Leap 15.5

Additional context

• This is using a downstream package.
• I tried setting ipv6: True and enable_fqdns_grains: False in the minion configuration with no change in behavior.