Use message IDs as an index

[stephenfin]

Though the Message-ID header is not guaranteed to be unique, it seems folks do like using this as a reference. The freedesktop fork, Mailman 3.0, and QEMU's "patches" tool, all make use of this. We probably should too.

If we do this, we'd probably want a migration to remove the < and > characters currently stored in the database. Apparently this is possible using the TRIM or REPLACE operations. TRIM is supported by both MySQL and PostgreSQL, while REPLACE can be cascaded/chained to replace multiple characters in one operation.

We would probably also want to add a message_id attribute to the Series model, to allow downloading a series by Message-ID. Alternatively, we could just return the series with a patch containing a given Message-ID. Either-or.

[daxtens]

We do enforce uniqueness of (message-id, project) pairs at the DB level. This is the only cause of emails failing to parse I see in my deployments.

[daxtens]

If we do lookups by msg-id then we should do this; otherwise we probably shouldn't as indicies are not free to build.

[stephenfin]

We do enforce uniqueness of (message-id, project) pairs at the DB level. This is the only cause of emails failing to parse I see in my deployments.

@daxtens So we'd probably want to have URLs like so for both the REST API and web UI:

/project/{projectID}/patches/{messageID}/

and maybe even deprecate the /patches/{patchID} endpoint in the REST API (we could keep the web UI as a shortlink and redirect)

I'd love it if searching by message-id was possible - would make integration with mail clients (i.e. notmuch) a lot easier, as there, the primary key is message-id.

[mricon]

I suggest that we add a "permalink" button in the same row as "id|diff|mbox|series" that would be in the following format:

example.com/p/list-id/msg-id

From experience, people will often mention patchwork URLs in commits (even if they are not supposed to):

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?qt=grep&q=patchwork.kernel.org

However, the numeric patch-id does not offer enough context for someone to get information about the mailing list conversation should the patchwork service go away -- say, 10-15 years in the future. If, on the other hand, patchwork provided an easy way to obtain a unique permalink that included both the list-id and the message-id of the submission, that would allow future code historians a way to track down mailing list conversations even if patchwork is dead and gone.