RESTWS-975: Implement Resource Schema Introspection Endpoint

[capernix]

Description of what I changed

Overview

This PR adds a new schema introspection endpoint to the OpenMRS REST API that allows clients to dynamically discover all available properties for any REST resource. This feature enhances the API's usability and enables more flexible client implementations.

The implementation includes a service layer component that uses Java reflection to determine resource delegate types and their properties, along with a REST controller that exposes this functionality at /rest/v1/schemaintrospector/{resourceName}. This feature enables more flexible client implementations by providing comprehensive information about available properties, their types, and inheritance relationships, allowing frontend developers to build dynamic interfaces and select properties for custom representations without having to manually explore the API structure. The code is thoroughly tested with unit tests covering both service and controller components to ensure reliability.

The implementation includes three test classes:

SchemaIntrospectionServiceImplTest: Tests the service-layer functionality
SchemaIntrospectionControllerTest: Tests the controller with mocked dependencies
SchemaIntrospectionTest: Tests property discovery on actual OpenMRS domain classes

Picture attached is the JSON being successfully obtained for the patient resource.

Issue I worked on

https://openmrs.atlassian.net/browse/RESTWS-975

Checklist: I completed these to help reviewers :)

• [ x] My IDE is configured to follow the code style of this project.

  No? Unsure? -> configure your IDE, format the code and add the changes with git add . && git commit --amend

• [x] I have added tests to cover my changes. (If you refactored
  existing code that was well tested you do not have to add tests)

  No? -> write tests and add them to this commit git add . && git commit --amend

• [x] I ran mvn clean package right before creating this pull request and
  added all formatting changes to my commit.

  No? -> execute above command

• [x] All new and existing tests passed.

  No? -> figure out why and add the fix to your commit. It is your responsibility to make sure your code works.

• [x] My pull request is based on the latest changes of the master branch.

  No? Unsure? -> execute command git pull --rebase upstream master

[chibongho]

Thanks @capernix , This is a great PoC for the OpenAPI project. Can you mark it as a draft for now? Some initial comments:

• Open questions: Should we have this be exposed as a Controller endpoint? (My gut says no, as we eventually want the OpenAPI generation to be a build-time process)
• This PoC is not (yet) dependent on OpenAPI / Swagger, which is great because it means it shouldn't interfere with ongoing work to upgrade OpenAPI (PR here).

[capernix]

Thanks @capernix , This is a great PoC for the OpenAPI project. Can you mark it as a draft for now? Some initial comments:

• Open questions: Should we have this be exposed as a Controller endpoint? (My gut says no, as we eventually want the OpenAPI generation to be a build-time process)
• This PoC is not (yet) dependent on OpenAPI / Swagger, which is great because it means it shouldn't interfere with ongoing work to upgrade OpenAPI (PR here).

What would you recommend then sir if not as controller endpoint? I'll think about alternate ways

[chibongho]

Well, we just need it to be used during a build step, right?