Hostname not resolvable inside related containers

### Issue Description

When you use `--hostname` on `podman run`, it's expected to hostname filled be resolvable inside the container itself and other containers that connect with this container. Actually the hostname is resolvable only inside container itself.

Based on discuss in podman-compose repo. https://github.com/containers/podman-compose/discussions/730

### Steps to reproduce the issue

Steps to reproduce the issue
1. Execute `podman-compose up -d` in a project that hostname defined is different from service name.
2. Enter in one of containers and try to ping each other by hostname, not service name.

### Describe the results you received

Related container hostname not resolvable.
```
/var/www/html # hostname
superweb2
/var/www/html # ping superweb1
ping: bad address 'superweb1'
```

### Describe the results you expected

Expected to ping related container by their hostname
```
/var/www/html # hostname
superweb2
/var/www/html # ping superweb1
PING superweb1 (172.20.0.3): 56 data bytes
64 bytes from 172.20.0.3: seq=0 ttl=64 time=0.474 ms
```

### podman info output

```yaml
host:
arch: arm64
buildahVersion: 1.30.0
cgroupControllers:
- cpu
- io
- memory
- pids
cgroupManager: systemd
cgroupVersion: v2
conmon:
package: conmon-2.1.7-2.fc38.aarch64
path: /usr/bin/conmon
version: 'conmon version 2.1.7, commit: '
cpuUtilization:
idlePercent: 99.92
systemPercent: 0.04
userPercent: 0.03
cpus: 1
databaseBackend: boltdb
distribution:
distribution: fedora
variant: coreos
version: "38"
eventLogger: journald
hostname: localhost.localdomain
idMappings:
gidmap:
- container_id: 0
host_id: 1000
size: 1
- container_id: 1
host_id: 100000
size: 1000000
uidmap:
- container_id: 0
host_id: 501
size: 1
- container_id: 1
host_id: 100000
size: 1000000
kernel: 6.3.12-200.fc38.aarch64
linkmode: dynamic
logDriver: journald
memFree: 1591521280
memTotal: 2048544768
networkBackend: netavark
networkBackendInfo:
backend: ""
dns: {}
ociRuntime:
name: crun
package: crun-1.8.5-1.fc38.aarch64
path: /usr/bin/crun
version: |-
crun version 1.8.5
commit: b6f80f766c9a89eb7b1440c0a70ab287434b17ed
rundir: /run/user/501/crun
spec: 1.0.0
+SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +CRIU +LIBKRUN +WASM:wasmedge +YAJL
os: linux
pasta:
executable: ""
package: ""
version: ""
remoteSocket:
exists: true
path: /run/user/501/podman/podman.sock
security:
apparmorEnabled: false
capabilities: CAP_CHOWN,CAP_DAC_OVERRIDE,CAP_FOWNER,CAP_FSETID,CAP_KILL,CAP_NET_BIND_SERVICE,CAP_SETFCAP,CAP_SETGID,CAP_SETPCAP,CAP_SETUID,CAP_SYS_CHROOT
rootless: true
seccompEnabled: true
seccompProfilePath: /usr/share/containers/seccomp.json
selinuxEnabled: true
serviceIsRemote: true
slirp4netns:
executable: /usr/bin/slirp4netns
package: slirp4netns-1.2.0-12.fc38.aarch64
version: |-
slirp4netns version 1.2.0
commit: 656041d45cfca7a4176f6b7eed9e4fe6c11e8383
libslirp: 4.7.0
SLIRP_CONFIG_VERSION_MAX: 4
libseccomp: 2.5.3
swapFree: 0
swapTotal: 0
uptime: 63h 26m 37.00s (Approximately 2.62 days)
plugins:
authorization: null
log:
- k8s-file
- none
- passthrough
- journald
network:
- bridge
- macvlan
- ipvlan
volume:
- local
registries:
search:
- docker.io
store:
configFile: /var/home/core/.config/containers/storage.conf
containerStore:
number: 2
paused: 0
running: 2
stopped: 0
graphDriverName: overlay
graphOptions: {}
graphRoot: /var/home/core/.local/share/containers/storage
graphRootAllocated: 106769133568
graphRootUsed: 3754766336
graphStatus:
Backing Filesystem: xfs
Native Overlay Diff: "true"
Supports d_type: "true"
Using metacopy: "false"
imageCopyTmpDir: /var/tmp
imageStore:
number: 1
runRoot: /run/user/501/containers
transientStore: false
volumePath: /var/home/core/.local/share/containers/storage/volumes
version:
APIVersion: 4.5.1
Built: 1685123899
BuiltTime: Fri May 26 18:58:19 2023
GitCommit: ""
GoVersion: go1.20.4
Os: linux
OsArch: linux/arm64
Version: 4.5.1
```

### Podman in a container

No

### Privileged Or Rootless

Rootless

### Upstream Latest Release

Yes

### Additional environment details

Additional environment details

### Additional information

Additional information like issue happens only occasionally or issue happens with a particular architecture or on a particular setting

Start by reproducing the issue with `podman-compose up -d` using service hostnames that differ from service names, then test hostname resolution between the related containers. Compare the observed lookup with the expected ping behavior; the work is done when each related container resolves the others by its configured hostname.

Written by the indexing model from the issue text.