Bug: "full' id generator is not stable

The "full" id generator currently take the hash of the input message as parsed by MM3 or by a Python email package. The parsed message may be massaged e.g. by adding an 'archived-at' header before it is converted into bytes.

Whilst this guarantees uniqueness, it is not repeatable.

If the same message is reloaded from a different source - or even the same source, if the 'archived-at' header is not present - it will get a different id, and thus may be stored as well as the original identical message.

If the database has to be regenerated from source, the message ids will be different. Since the message ids are used to create Permalinks, any existing Permalinks will stop working.

The generator also uses the same output format as the "medium" generator, which may cause problems in future.

No file, test, or entry point is named. Start by locating the "full" and "medium" id generators and tracing how parsed messages from MM3 or the Python email package become bytes and database keys. Done means identical messages receive repeatable ids regardless of added "archived-at" headers, while the full generator's output format is distinct from the medium generator and existing permalink behavior is covered.

Written by the indexing model from the issue text.