Why do we need the stress test for UEFI runtime service GetNextHighMonotonicCount?

Hi FWTS owners and experts,

Do you know why we need to do the stress test for UEFI runtime service GetNextHighMonotonicCount? I saw it was added by the commit below, but I don't see any reason.
   - https://github.com/ColinIanKing/fwts/commit/ad3bb059b3a54bf21555e01f57ea0c4fcc2e434a

Since the edk2 GetNextHighMonotonicCount implementation below would set a UEFI variable, running this stress test would use up the space of the UEFI variable store and then cause the failures with other test cases that are also related to the UEFI variable.
 - https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Universal/MonotonicCounterRuntimeDxe/MonotonicCounter.c

We run into this issue on several ARM embedded platforms (non-server and non-workstation systems) like RPi4 because it is common to see that ARM embedded platforms allocate NVRAM space less than 64k for UEFI variable store.

For reproducing this issue, you just need to run FWTS uefirtmisc test twice on RPi4. Each uefirtmisc test would take 36k, so you would run into this issue at the second time run.

Therefore, if we have no reason to do the stress test, can we remove it? If we have a reason, can we have a flag to enable/disable GetNextHighMonotonicCount stress test?

Furthermore, can we also reduce the value of uefi_set_variable_multiple to 20? The current setting (40) would also take 14k that is a little bit much for the ARM embedded devices (non-server and non-workstation systems).

For more information, please check https://github.com/pftf/RPi4/issues/163.

Best Regards,
Sunny