protoc-gen-openapi: fix schema name collision for deeply nested messages

[DenKoren]

Summary

getMessageName in cmd/protoc-gen-openapi/generator/reflector.go only walked one parent level when building OpenAPI schema names from nested protobuf messages. This caused schema name collisions for messages nested 3+ levels deep.

Example: Given these proto definitions in the same package:

message A {
  message Create {
    message Request { ... }
  }
}

message B {
  message Inner {
    message Create {
      message Request { ... }
    }
  }
}

The old code produced Create_Request for both, because it only prepended the immediate parent (Create). Only the first schema survived in the generated OpenAPI spec — the others silently reused its (structurally incorrect) definition.

Backward compatibility

For backward compatibility, no_recursive_schema_naming option is introduced. If you need old behaviour, set this option to the generator via --openapi_ipt="no_recursive_schema_naming=true".

Default behaviour changed as old behaviour produced a bug in generated openapi spec that was hard to notice.

Fix

Replace the single-parent if check with a for loop that walks the full message hierarchy:

• A.Create.Request → A_Create_Request
• B.Inner.Create.Request → B_Inner_Create_Request

Tests

• Existing tests pass — fixtures use at most 1 level of nesting, which was already handled correctly by both old and new code
• Verified against a real-world proto API with 3-4 levels of message nesting — all schemas are now correctly disambiguated with unique names