Migrate to Apicurio 3.1 client libraries

[MikeEdgar]

• update Apicurio client and serializer/deserializer to latest 3.1 release
• adjust custom client support in API server (provides authentication and SSL integration to match other clients used by the console)
• refactor console's custom serializer and deserializer to account for API changes in Apicurio's Avro and Protobuf ser/des classes
• Update integration tests to verify support for both Apicurio v2.6 and v3.1 registry servers

[MikeEdgar]

@carlesarnal @EricWittmann, FYI if you have some spare cycles to check it and point out potential issues.

[EricWittmann]

I'm surprised that the creation of the client facade is as complicated as it needs to be (including providing custom versions of Kiota classes) even though you warned me about it. :)

Despite that, it's pretty straightforward and seems OK to me. I'm less confident in my ability to jude the SerDe stuff. But that seems good to me as well.

[MikeEdgar]

I'm surprised that the creation of the client facade is as complicated as it needs to be (including providing custom versions of Kiota classes) even though you warned me about it. :)

The complexity with the client facade comes down to two things, both arising from a common way we allow for clients (Apicurio, Prometheus, & Kafka Connect) to be configured in the console

1. add SSLContext to the client
2. inject authentication information generically, which can be basic auth, OIDC, or user-provided bearer tokens

The custom Kiota stuff will probably be removed now that you've made it configurable in the Apicurio code, but I still have it in there from an earlier iteration.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
90.3% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud