test: temporarily adjust the default mount rate limit

test: temporarily adjust the default mount rate limit

(Hopefully) a temporary workaround for #30573 where starting a user
session when PID 1 is rate limited stalls even after it leaves the rate
limited state:

[   11.658201] H systemd[1]: Sent message type=signal sender=n/a destination=n/a path=/org/freedesktop/systemd1 interface=org.freedesktop.systemd1.Manager member=UnitRemoved cookie=4208 reply_cookie=0 signature=so error-name=n/a error-mes>
[   11.658233] H systemd[1]: Event source 0x559babdd8bb0 (mount-monitor-dispatch) left rate limit state.
[  101.562697] H busctl[784]: Failed to get credentials: Transport endpoint is not connected
[  101.563480] H systemd[1]: systemd-journald.service: Got notification message from PID 300 (WATCHDOG=1)
[  101.563725] H testsuite-74.sh[784]: BusAddress=unixexec:path=systemd-run,argv1=-M.host,argv2=-PGq,argv3=--wait,argv4=-pUser%3dtestuser,argv5=-pPAMName%3dlogin,argv6=systemd-stdio-bridge,argv7=-punix:path%3d%24%7bXDG_RUNTIME_DIR%7d/bus
[  101.564136] H systemd[1]: Successfully forked off '(sd-expire)' as PID 787.
[  101.564754] H systemd[1]: Successfully forked off '(sd-expire)' as PID 788.
[  101.564831] H testsuite-74.sh[381]: + echo 'Subtest /usr/lib/systemd/tests/testdata/units/testsuite-74.busctl.sh failed'

The issue appeared after ee07fff03b which does a bunch of mounts/umounts
that get PID 1 into a rate limited state, and is frequent enough to be
annoying, so let's temporarily bump the rate limit to alleviate that.