chown -R on non-empty directory changes mtime

Not sure if this is a bug or an 'unavoidable feature'; fuse-overlayfs 1.12, ext4 on the underlying filesystem. It's causing me a little trouble with some buildah builds!

```
#! /bin/bash

runtest () {
local testd=$1
orig=$(stat -c %Y $testd/testdir)

sleep 1

chown -R $USER:$GROUP $testd/testdir

new=$(stat -c %Y $testd/testdir)

if [ $new -ne $orig ]; then
echo "mtime changed from $orig to $new!"
else
echo "mtime unchanged"
fi
}

echo -e "\nRunning test using fuse-overlayfs:\n"

d=`mktemp -d -p $PWD`

mkdir -p $d/upper $d/lower $d/work $d/mnt

mkdir $d/lower/testdir
touch $d/lower/testdir/testfile

fuse-overlayfs -V
fuse-overlayfs -olowerdir=$d/lower,upperdir=$d/upper,workdir=$d/work $d/mnt

echo
runtest $d/mnt

umount $d/mnt

rm -r $d

echo -e "\n\nRunning test WITHOUT fuse-overlayfs:\n"

d=`mktemp -d -p $PWD`
mkdir $d/testdir
touch $d/testdir/testfile

runtest $d
echo

rm -r $d
```
Yields:
```
Running test using fuse-overlayfs:

fuse-overlayfs: version 1.12
FUSE library version 3.10.5
using FUSE kernel interface version 7.31
fusermount3 version: 3.10.5

mtime changed from 1691229966 to 1691229967!

Running test WITHOUT fuse-overlayfs:

mtime unchanged
```

Start by running the shell reproducer from the issue with fuse-overlayfs 1.12 and compare its output with the plain ext4 case. Trace the directory metadata handling around recursive chown and overlay mounts. Done means determining whether the mtime change is expected and, if not, identifying a reproducible regression and a suitable correction.

Written by the indexing model from the issue text.