Suggestion: Production settings for domain.xml

Overview of the Suggestion Suggest settings different from those in Payara's community version domain1 that are more suited to production environments - in terms of performance, scalability, and security.

What kind of user is the suggestion intended for?
(Example users roles: API User, Curator, Depositor, Guest, Superuser, Sysadmin) sysadmin

What inspired this idea? looking through https://docs.payara.fish/community/docs/5.201/documentation/payara-server/production-ready-domain.html and https://github.com/gdcc/dataverse-kubernetes/issues/218, etc.

What existing behavior do you want changed? We should give guidance (e.g. maybe an Admin/Production settings guide?) and/or just suggest changes to the default domain.xml that people should use. For example, to make it easier to see what changes Payara makes between versions to domain.xml, I've started keeping a copy, modified to show where the Dataverse instance specific changes should get added. This commit: https://github.com/QualitativeDataRepository/dataverse/commit/d34f994c7a647d059c6520b726d0bdd5421e599f shows the recommended changes I've been trying so far.

Are you thinking about creating a pull request for this issue?
I'd suggest, as a first step that some performance testing (or test use on Harvard production) be tried with the changes suggested in the commit (and perhaps the ones from https://github.com/gdcc/dataverse-kubernetes/issues/218 as well?) and, if they help, that we use this issue to trigger a PR for some guide material and perhaps an example domain as in the QDR repo.

Start with the Payara production-ready-domain guide, domain.xml, and the QDR commit referenced in the issue; compare those changes with the suggestions in dataverse-kubernetes issue 218. Validate proposed settings through performance testing or production use, then document the evidence in a production guide or example domain.xml.