Ensure SSL truststore is present at startup

[HoussemNasri]

Follow up on #8583.

• Change in CHANGELOG.md described in a way that is understandable for the average user (if applicable)
• Tests created for changes (if applicable)
• Manually tested changed features in running JabRef (always required)
• Screenshots added in PR description (for UI changes)
• Checked developer's documentation: Is the information available and up to date? If not, I outlined it in this pull request.
• Checked documentation: Is the information available and up to date? If not, I created an issue at https://github.com/JabRef/user-documentation/issues or, even better, I submitted a pull request to the documentation repository.

[Siedlerchr]

Just a general question: Does the trustsotre content change with the java version? I might guess that new certifacates are added or revoked. So we need to ensure that we always copy the jdk's truststore in our resources and maybe also merge? the contents when the store already exists from an older version?

[calixtus]

Thanks for the follow up!

[HoussemNasri]

@Siedlerchr That is correct; in JDK 17 they removed Telia Company's Sonera Class2 CA Certificate and added 2 HARICA Root CA Certificates. Merging new JDK truststore is an option; it can be done in 3 steps:

1. Add new truststore to resources.
2. Remove all jdk certificates from the old truststore at startup.
3. Finally, update the old truststore with new truststore certificates.

JDK certificates alias follow a specific pattern, so we can filter them in to remove them.

[Siedlerchr]

Thanks for the explanation. Okay, this seems like it could be implemented as part of a migration process in JabRef.