Backfill gets clogged up with fake prev_events when using the MSC2716 /batch_send endpoint

[MadLittleMods]

Spawning from #11027 (comment)

---

When using the experimental MSC2716 /batch_send endpoint, we're using a fake prev_event to make the chain of historical state and messages float off on their own in the DAG and nudges federated homeservers to ask for the state at the start of the chunk that we generated.

Each time one of these fake prev_events is processed by the homeserver, it's seen as a backward extremity which we attempt to fetch when trying to do backfill federation things but will never resolve. This is problematic as we will have thousands of batches per room to backfill a big room for Gitter and will have to deal with thousands of backward extremities here. Since we use get_oldest_event_ids_with_depth_in_room and oldest backward extremities will always be our historical events. Assuming we're paginating from the bottom (where current_depth > historical extremity depth), we will always pick the 5 unresolvable fake events in the room to backfill from. This would stop us from backfilling any other events in the room.

Potential solutions

• Ignore fake event ID's and never put as a backward extremity
  • I don't know how we do this for remote homeservers though.
• Back-off backfilling a certain event when they fail to fetch
• Can we just have no prev_events for a given event? How does the first event in the room work?

The solution might be intertwined with #10764.

Reproduction case

Untested for sure (just theoretical): Send more than 5 batches of historical messages. Try to backfill messages from another server.

There is a Complement test which does many batches but doesn't test the backfill aspect, matrix-org/complement#212