`conflict_detection` endpoint isn't robust to large timetables

What happened?

When accessing http://localhost:4000/api/timetable/3/conflicts?infra_id=3 on a timetable that contained roughly 16k trains, I received an error editoast:coreclient:MqClientError.

Logs contain this:

osrd-rabbitmq         | 2025-04-29 12:40:45.775635+00:00 [error] <0.1060.0> Channel error on connection <0.840.0> (172.18.0.10:59004 -> 172.18.0.7:5672, vhost: '/', user: 'osrd'), channel 8:
osrd-rabbitmq         | 2025-04-29 12:40:45.775635+00:00 [error] <0.1060.0> operation basic.publish caused a channel exception precondition_failed: message size 2255097625 is larger than max size 536870912
osrd-editoast         |   2025-04-29T12:40:45.775874Z ERROR lapin::channel: Channel closed, channel: 8, method: Close { reply_code: 406, reply_text: ShortString("PRECONDITION_FAILED - message size 2255097625 is larger than max size 536870912"), class_id: 60, method_id: 40 }, error: AMQPError { kind: Soft(PRECONDITIONFAILED), message: ShortString("PRECONDITION_FAILED - message size 2255097625 is larger than max size 536870912") }

(meaning 2150mb, while the max size is at 512mb)

How can we reproduce it (as minimally and precisely as possible)?

Create a timetable with 16k trains. It doesn't have to be realistic, 16k of the same train should work.

Then try to compute its conflicts.

On which environments the bug occurs?

Local

On which browser the bug occurs?

Firefox

OSRD version (top right corner Account button > Informations)

ca62af0d82ccc2926f662327b335db6bff78c7c8

Start at the conflict_detection endpoint and reproduce the failure with a timetable containing roughly 16k trains. Trace the RabbitMQ publish path using the reported MqClientError and 512 MiB message limit as the starting clues. Done means conflict computation no longer fails because it publishes an oversized message.