Avoid using generated Jackson serializers for subclasses

[mariofusco]

Fixes #46156

The reason why it requires 2 different endpoints to reproduce the problem is the following: in the reproducer one endpoint returned objects of class A and the second of class B extending A. The serializer for A is correctly generated and registered. Conversely the serializer for B cannot be generated because the class contains an unknown annotation (JsonIgnore in this case, but this pull request also adds support for it), so Jackson should use the default, reflection based, serializer. However, as discussed here since there's a registered serializer for A and B is also an instance of A, Jackson decides to use the serializer generated for A, thus leaving out the properties of B during serialization. Without the endpoint returning instances of A, no serializers is generated for that class, so the problem doesn't happen. Note that this problem also doesn't happen for deserializers because (for some reason) in that case Jackson use a generated deserializer only if there is one registered exactly for it.

[quarkus-bot]

Status for workflow Quarkus CI

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

✅ 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.

You can consult the Develocity build scans.