[HLAPI] Add some missing timeline properties

[cconard96]

Checklist before requesting a review

• I have read the CONTRIBUTING document.
• I have performed a self-review of my code.
• I have added tests that prove my fix is effective or that my feature works.

Description

Requires #21611

Add several properties than were missing related to ITIL items and the timeline items:

• uuid, user_tech, group_tech, date, date_creation, date_mod, planned_begin, planned_end, timeline_position, source_item_id, and source_of_item_id properties for the applicable Ticket, Change and Problem Task schemas in the High-Level API v2.1.
• date, timeline_position, source_item_id, and source_of_item_id properties for the Followup schema in the High-Level API v2.1.
• approver, approval_followup, date_creation, date_mod, and date_approval properties for the Solution schema in the High-Level API v2.1.
• timeline_position property for the TicketValidation, ChangeValidation and Document_Item schemas in the High-Level API v2.1.
• date_solve, date_close, and global_validation properties for the applicable Ticket, Change and Problem schemas in the High-Level API v2.1.

[cconard96]

May I ask why this is planned for 11.1? The new API has its own versioning and is capable of supporting multiple versions at the same time for schemas and endpoints. The new properties in this PR will be exclusive to version 2.1 and if users request v2.0 (/api.php/v2.0/), these new properties will not be used.
The only true BC break will be when API versions get removed or there is some change that cannot be properly versioned.
The API versioning and pinning strategies were explained in the new API's getting started documentation.

In fact, I planned to open a PR soon to add an API version pinning feature for Webhooks to allow users to pin their webhooks to specific API versions to try to keep them stable as the API evolves.

[cedric-anne]

May I ask why this is planned for 11.1?

To be honnest, I cannot tell which milestone should be targetted. If we continue to add small enhancements in the 11.0 version, then we will probably require a few months to stabilize it, like we did for the 10.0 version, and we will not be able to focus on the 11.1 release.

[cconard96]

IMO, new schemas and endpoints are some of the safest changes that can be made in a bugfix GLPI version. Given that there are a lot of things missing in the new API at the same time we are pushing people away from the legacy API, I believed improving on coverage during 11.0.X would be better than waiting 6 months or more for 11.1.

There are other types of API changes which I would want to wait of course, like the introduction of cursor-based pagination which offers much better performance than offset-based pagination (if I can comfortably get it working reliably with complex filters).

[cconard96]

The one thing I want to avoid though is having a new minor version of the API with only one or two additions.

[orthagh]

List of id for HLAPI missing endpoints or data: #21335, #21369, #21537, #21539, #21541
If they are well tested, CI green and are filling gaps in the new API, I'm in favor to include them in 11.0.2 or the next 11/bugfixes version.
There are notably missing data (fields or endpoints) in the new implementation we need to fix without waiting 1 year to be available.

To moderate a bit my thoughts, these PR shouldn't include BC breaks or only if delivered API endpoint is bugged
For me, the listed PR are OK.