Add tests to the TLS certificate reload

[cescoffier]

This PR uses the new certificate generator utility.

Once in, we will be able to remove all the hand-crafted certificates.

[github-actions]

🙈 The PR is closed and the preview is expired.

[cescoffier]

Ok... I broke everything :-). Will have a look Monday.

[sberyozkin]

@cescoffier Sorry, also missed the review request, it looks promising in any case 👍

[quarkus-bot]

Status for workflow Quarkus Documentation CI

This is the status report for running Quarkus Documentation CI on commit fd46a61.

✅ The latest workflow run for the pull request has completed successfully.

It should be safe to merge provided you have a look at the other checks in the summary.

⚠️ There are other check runs running, make sure you don't need to wait for their status before merging.

[quarkus-bot]

Status for workflow Quarkus CI

This is the status report for running Quarkus CI on commit fd46a61.

Failing Jobs

Status	Name	Step	Failures	Logs	Raw logs	Build scan
✖	Native Tests - Data5	Build	Failures	Logs	Raw logs	🚧

Full information is available in the Build summary check run.

Failures

⚙️ Native Tests - Data5 #

- Failing: integration-tests/jpa-postgresql-withxml 

📦 integration-tests/jpa-postgresql-withxml

✖ io.quarkus.it.jpa.postgresql.ImageMetricsITCase.verifyImageMetrics line 15 - History - More details - Source on GitHub

org.opentest4j.AssertionFailedError: Expected analysis_results.fields.reflection to be within range [163 +- 3%] but was 168 ==> expected: <true> but was: <false>
	at org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
	at org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
	at org.junit.jupiter.api.AssertTrue.failNotTrue(AssertTrue.java:63)
	at org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:36)
	at org.junit.jupiter.api.Assertions.assertTrue(Assertions.java:214)
	at io.quarkus.test.junit.nativeimage.NativeBuildOutputExtension.assertValueWithinRange(NativeBuildOutputExtension.java:90)
	at io.quarkus.test.junit.nativeimage.NativeBuildOutputExtension.lambda$verifyImageMetrics$0(NativeBuildOutputExtension.java:66)

[cescoffier]

@sberyozkin Fixed! Your review would be much appreciated.

The goal is to use this technique to avoid hand-crafted certificates. Here, it's slightly more complicated as I'm testing the hot reload, which means I need two sets of certificates: the initial certificate and the one triggering the reload.

In the other case, we should have only one.

Also, while adding that feature to the REST client, we discovered that the REST client did not support PEMs and P12 (getting fixed right now), and the trust store format needs to be completed. It is the case with gRPC, too. Because creating certificates was painful, I can understand why it was not adequately tested. So, a consequence would be the addition of more certificate formats in various extensions.

[geoand]

Nice!

[gsmet]

@cescoffier I don't think this should be in the BOM. I would move it to the build-parent.

[cescoffier]

Ok, I will do that in my next PR about kafka TLS support (which as I needed to fix something in the junit5 extension)