Add transit service validity dates and CPU cores to GraphQL ServerInfo

[svedbod]

Is your feature request related to a problem? Please describe.

We are syncing to lastest OTP and need to replace functionality previously available through the
REST API /otp/routers/default endpoint. This endpoint provided information about the OTP server
including transit service validity dates (start/end) and server hardware specs (CPU cores). The
REST endpoints have been removed/deprecated in favor of GraphQL, but the GraphQL serverInfo query doesn't
expose all the information we need.

Goal / high level use-case

Enable API consumers to retrieve complete OTP server information through a single GraphQL query, including:

• Transit data validity period (when does the loaded GTFS/Netex data start and end)
• Server hardware information (number of CPU cores for capacity planning)

This information is essential for:

1. Monitoring and alerting when transit data is expiring
2. Client-side validation to prevent trip planning outside valid date ranges
3. Capacity planning and load balancing decisions
4. Service health checks and operational dashboards

Describe the solution you'd like

Add three new fields to the GraphQL ServerInfo type:

type ServerInfo {
  # ... existing fields ...

  "Number of CPU cores on the OTP server"
  numberOfCores: Int

  "Start date of the transit data validity period"
  transitServiceValidityStart: Date

  "End date of the transit data validity period"
  transitServiceValidityEnd: Date
}

Implementation

• numberOfCores: Use Runtime.getRuntime().availableProcessors() to return the number of processors available to the JVM (cross-platform, works on Linux/macOS/Windows)
• transitServiceValidityStart: Call TransitService.getTransitServiceStarts().toLocalDate() and return as Date scalar (ISO 8601 format like "2025-01-15")
• transitServiceValidityEnd: Call TransitService.getTransitServiceEnds().toLocalDate() and return as Date scalar (ISO 8601 format)

Describe alternatives you've considered

1. Query all authorities and service journeys: We currently work around this by querying all authorities and
   iterating through their service journeys to find min/max dates. This is inefficient, slow, and creates
   unnecessary load on the GraphQL endpoint.
2. Use REST API endpoints: The old REST endpoints are deprecated and not available in newer OTP versions.
3. External monitoring: Monitor the GTFS/Netex source files separately, but this doesn't reflect what OTP
   actually loaded and is using.

Additional context

The transit service validity dates are already tracked internally by OTP in
TimetableRepository.getTransitServiceStarts() and getTransitServiceEnds(). This feature request simply exposes
this existing data through the GraphQL API.

This would make the GraphQL serverInfo query a complete replacement for the legacy REST endpoint.

[t2gran]

• The transitServiceValidity(Start|End) does not belong in ServerInfo. Be also aware that these are not from the data, but from the config. They are however the right thing to use for clients who want to validate the date before sending a request.
• The numberOfCores is ok.

This might be relevant, from doc of ServerInfo:

Information about the deployment. This is only useful to developers of OTP itself. It is not recommended for regular API consumers to use this type as it has no stability guarantees.

The best thing to do is to create a new root level type TransitInfo and in there have a validityPeriod : ValidityPeriod. There are already a validityPeriod type in Siri SX, but the naming is wrong(lower case first), and it is not generic.

[optionsome]

In the GTFS API, we also have a separate serviceTimeRange query on the root level. So it would be inline with that.

The current validityPeriod type uses DateTime scalar instead of Date scalar. Should we have a time range type with Date level accuracy?

[optionsome]

Although, it seems like the start and end of the transit service are modeled as ZonedDateTimes in the internal model so maybe the accuracy is indeed DateTime level instead of on Date level?