Feature/protobuf java payload generation

[bascunansalvador]

The previous implementation could preserve native Protobuf schemas as .proto artifacts, and generated Spring Kafka clients could reference Protobuf payload types when the schema declared the right package information. However, the generator did not actually generate the Java Protobuf message classes itself.

That meant the type-safe Protobuf Kafka path was incomplete. A generated producer or consumer could reference com.example.protobuf.UserCreated, but the consuming project still had to run Protobuf code generation separately to make that class exist.

For the proposed solution, native Protobuf generation now supports Java message source generation from Protobuf schemaFormat payloads. The generator writes the .proto schema artifact to the resource output directory and, by default, also runs protoc to generate Java Protobuf message sources into the Java source output directory.

This keeps the Protobuf payload model contract-driven. A native Protobuf AsyncAPI schema can now produce both the native schema artifact and the Java message type that Spring Kafka APIs reference.

The Protobuf schema must provide enough information for Java generation. It needs either option java_package = "..."; or a Protobuf package ...;, it must enable option java_multiple_files = true;, and it must contain a top-level message matching the AsyncAPI payload name. When those requirements are not met, the generator now fails with a domain-specific error explaining what is missing.

The new behavior is exposed through the typed generator configuration and through all frontends.

For Maven, native Protobuf configuration now supports generateJavaMessageTypes.

For Gradle, schemas.nativeProtobuf.generateJavaMessageTypes is available on the extension and wired into the task input.

For CLI usage, the new option is --schemas-native-protobuf-generate-java-message-types true|false.

Java message generation defaults to true when native Protobuf generation is enabled. Users can set it to false when they only want .proto artifacts.

The generated Java message sources are routed as JAVA_SOURCE artifacts, so they are written to the Java source output directory instead of the resource output directory. The .proto files remain resource/schema artifacts.

The implementation uses protoc through protoc-jar, with an explicit Protobuf compiler version aligned with the protobuf-java runtime dependency. This is important because the older bundled/default compiler path does not work reliably on Apple Silicon.

The test coverage was expanded in several layers.

Core generator tests now verify that native Protobuf generation returns .proto artifacts and Java source artifacts when Java message generation is enabled. The generated Java sources are also compiled in tests against the current test classpath.

A runtime-style Protobuf test was added as well. It loads the generated UserCreated class, builds a message through the generated builder API, serializes it with toByteArray(), parses it back with parseFrom(...), and verifies that the values survive the round trip. This gives us stronger confidence that the generated payload can become real Protobuf bytes.

Output contract tests verify that generated Protobuf Java message sources are written to the Java source output directory while .proto artifacts remain in the resource output directory.

Configuration, factory, and planner tests verify that the new generateJavaMessageTypes flag flows through the typed generator configuration into the planned native Protobuf artifact task.

CLI, Maven, and Gradle tests now cover both the default behavior and the opt-out behavior. When native Protobuf generation is enabled by default, UserCreated.java is generated. When generateJavaMessageTypes is set to false, the .proto file is still generated, but the Java message source is not.

The README and generator strategy documentation were updated to explain that native Protobuf generation now produces Java Protobuf message sources by default, while Kafka serializer/deserializer configuration and schema registry runtime wiring are still owned by the consuming application.