When we "shim" a message type into an UNSUPPORTED message, we put the original message we are wrapping into the unsupportedMessageInfo field.

Because the validators have this field type as t.Object, no ID conversion is done on it. This means that when the client unshims the UNSUPPORTED message, it will see a message where the ID conversion logic has not been run, and the id and threadID fields are not prefixed with the keyserver ID.

This causes ENG-8038, where the message disappears from the client UI once unshimmed. This diff solves that by modifying the validators.

The change here should actually not change how "permissive" the validators are; they should continue to succeed and fail in the same scenarios.

However, by listing earlier options in the t.union, we allow validators to perform ID conversion when those options match.

I excluded validators that are only shimming for codeVersions prior to the ID conversion.

This solution is unfortunately rather hacky, and forces us to have to maintain this list whenever introducing new types to shim. I considered specifying this on the message specs, but there's no way to do that without leading to an import cycle.

Open to other solutions, but if they require substantially more work I'd prefer to land this one for now, as the current behavior on master is broken.

Depends on D11870

I delivered a shimmed farcaster_mutual message to a local client, and then I triggered a migration to unshim it. I confirmed that it's now visible and rendered correctly, whereas it was previously being ignored by message-reducer.js's isThreadWatched check