Exclude protobuf-java from mysql-connector-j

[vjh0107]

Closes #13996

[electronicboy]

if the exposure of this in the API is not needed for connector-j then this really should be filed as a bug against them, can't really just remove libraries on a whim

[vjh0107]

mysql-connector-j exposing protobuf is fine in an isolated classloader, that's the setup it's built for. It only collides because Paper puts connector-j and its transitive protobuf on a classpath shared with plugins, which is Paper's call, not connector-j's. A shade upstream would help, but the conflict itself comes from a bundled lib's transitive deps leaking into plugin's code

[vjh0107]

I can put together an MRE that reproduces this if you'd be willing to take a look? @electronicboy

[electronicboy]

it is connector-j's call to expose protobuf as a dependency to their API consumers, not ours; Plugins have to be able to access the servers classpath, and so that has impacts on them and us; We can't just blindly remote a library here, if protobuf is NOT a runtime dependency for jconnector at all then jconnector should not expose it as a runtime dependency

[vjh0107]

you're right that it's connector-j's call but protobuf has a runtime dependency only for the X Protocol path.
standard JDBC never touches mysqlx, which is all plugins use. So it's a real runtime dep for connector-j as a whole, just not one that plugins actually rely on.

the reason I hit this at all is OpenTelemetry, which is a CNCF/Linux Foundation project and pretty much the standard for observability these days. It'd be a shame if the classpath collision effectively made OTLP unusable for plugins, so I'd like to see it resolved one way or another. Would you be able to raise this with the team once more down the line?