Improve SUT OS environment reproducibility

[franz1981]

As part of #55 we still have a missing piece left, which is very tied to how quarkus config parsing work on SmallRye: iirc (@radcortez can confirm 🙏) quarkus is very sensitive in both cpu and memory usage, at startup, by the number of defined environment variables where it runs.
Our SUT runs outside containers so we are at the mercy of the environment provided on the running server, which won't help in that; it could have bloated environment variables due to leftovers of other tests or just because is a polluted environment, and we risk to observe regressions or not reproducible results from users, because they have a much different environment.
I would suggest to run the server containerized to lessen this problem, but I am opened to suggestions from @radcortez on this, because IIRC we hit it with Matt Raible public framework public benchmark some time ago.

[radcortez]

This shouldn't be an issue anymore. Since we found out about it, we have been improving on how we do the parsing. Let me run some numbers, and I'll post them here later.

[radcortez]

Some of my preliminary numbers show a linear 2% increase in memory and a linear 5% increase in startup time for a large number of env vars (~500), compared to the test baseline of (~100).

This is with config-quickstart, so these numbers will be smaller when you factor in the other extensions' work. I don't find these very concerning, but there is probably some room for improvement.

One idea that I had some time ago was to reimplement parts of HashMap to avoid having to allocate new objects just to override equals and hashcode for the String comparisons and would also void allocating it for lookups. This is related to smallrye/smallrye-config#1295.

@franz1981 what do you think if we implement our own customized HashMap, that takes the original String, but uses our own custom equals and hashcode?