We previously took into account all possible Message-IDs found in the References header of incoming messages. We also don't try to match the `In-Reply-To` header separately, since it is supposed to be appended to the `References` header, when present.

This is all specified in RFC5322, section 3.6.4:
   https://datatracker.ietf.org/doc/html/rfc5322#section-3.6.4

However, for very long threads, the `References` field can contain dozens or even hundreds of previous Message-IDs, even though we generally care only about the last one.

This can be an issue for databases with a large number of messages, as the query planner could mistakenly choose a suboptimal plan (e.g. a Seq Scan or filtered Index Scan), rather than looping on the `message_id` index, which is the best plan.

Here we truncate the list of References to only include the last 32 ones. For most threads this will make no difference, as they have less than 32 referencs. For very long threads it should still pick up the last known Message-ID without trouble. And if the last 32 messages aren't known by the system, it's unlikely that the message should still be considered part of earlier threads - it's been sidetracked elsewhere.

PS: also simplify the `order` clause, as no secondary sort criterion is going to work after `ORDER BY id`.