OpenAPI schema generation and model inheritance

When using inheritance in model definitions, the behaviour is inconsistent.

Steps to reproduce

• Define a model that inherits from another Model/Entity
• Use the aforementioned model in any controller, so that the OpenAPI spec references it
• Run the server
• Check the schemas in the API Explorer

Current Behaviour

As noted, the behaviour is inconsistent, and depends upon the order of occurrence of the parent/child models.

• If the parent model is referenced first, the child model is represented as a 1:1 copy (even the name is identical) of the parent.
• If the child model is referenced first and schema-related functions are used somewhere in the code (most notably in decorators, as I suspect they are executed before anything else), both the models are represented as having the child's name and the parent's properties.
• If the child model is referenced first, and schema-related functions (e.g. getModelSchemaRef) are not used on the parent model, the schemas are generated correctly.

My guess is there is some sort of caching mechanism (which makes a lot of sense) for the generation of OpenAPI schemas. If so, this mechanism is broken when dealing with inheritance.

Expected Behaviour

Correct generation of both child and parent models' schemas, regardless of their occurrences' positions in controllers.

Acceptance Criteria

• Correct generation of both child and parent models' schemas, regardless of their occurrences' positions in controllers.
• Add tests to exercise this area
• Update docs accordingly.

Link to reproduction sandbox

https://github.com/ricky92/loopback-next/tree/model-inheritance

Additional information

Platform and node version: darwin x64 8.16.0

@loopback/example-todo@1.6.5
├── @loopback/boot@1.4.4
├── @loopback/context@1.20.2
├── @loopback/core@1.8.5
├── @loopback/openapi-v3@1.7.0
├── @loopback/repository@1.8.2
├── @loopback/rest@1.16.3
├── @loopback/rest-explorer@1.2.5
├── @loopback/service-proxy@1.2.5
└── loopback-connector-rest@3.4.1

Start with the linked reproduction sandbox and reproduce the inheritance-order cases in the API Explorer, focusing on schema-related functions such as getModelSchemaRef and decorator execution. Trace the OpenAPI schema-generation and caching path, then add tests covering parent-first and child-first references. Done means both schemas are correct in every stated order and the documentation is updated.