Performance issue with new stop place filtering logic

[vpaturet]

The new filtering logic on stop places and quays may lead to performance issues with queries that lack proper filtering.
This is a consequence of #6423

The filter on stop place ids:
"ids": []
used to be interpreted as: no id.
It is now interpreted as: all ids.

Whether this is a bug or not is debatable.
It can however significantly change the behavior and responsiveness of a production system.

Example:
The following query:

query stopPlaces($ids: [String!], $lines: [ID], $startTime: DateTime) {
  stopPlaces(
    ids: $ids
  ) {
    id
    name
    latitude
    longitude
    estimatedCalls(
      startTime: $startTime,
      timeRange: 72000,
      numberOfDepartures: 50,
      numberOfDeparturesPerLineAndDestinationDisplay: 5,
      arrivalDeparture: departures,
      includeCancelledTrips: true,
      whiteListed: {
        lines: $lines
      }
    ) {
      ...estimatedCallFields
    }
  }
}

fragment estimatedCallFields on EstimatedCall {
  quay {
    id
    publicCode
  }
  date
  aimedDepartureTime
  expectedDepartureTime
  destinationDisplay {
    frontText
    via
  }
  notices {
    text
  }
  situations {
    situationNumber
    reportType
  }
  serviceJourney {
    id
    journeyPattern {
      id
      line {
        id
        name
        publicCode
      }
    }
    transportMode
    transportSubmode
  }
  realtime
  cancellation
  predictionInaccurate
  occupancyStatus
}

used with the following parameters:

{
  "ids": [],
  "lines": [],
  "startTime": "2025-02-19T10:32:00.000Z"
}

will produce a very large response (round 280MB in the case of the Norwegian dataset)
The previous filtering logic would return en empty result set.

Version of OTP used (exact commit hash or JAR name)

latest dev-2.x

Data sets in use (links to GTFS and OSM PBF files)

Norwegian data.