While writing the code to edit/delete roles, I noticed that the message spec for the change_roles message type causes the app to crash if a role is deleted. The reason for this is when a user's role
is changed, we write the following information to the DB in the content field:
```
{"userIDs":["83813"],"newRole":"84094"}
```
To generate the robotext for this message in chat (so we can show users something like 'jack assigned max the "Moderators" role'), we introspect into `threadInfo.roles` and try to access the role info using
the `newRole` ID. When a role is deleted, we delete it from the database, and so the `threadInfo` will no longer have this role info and the app will crash. To resolve this, we should now store the `roleName`
associated with the role change in the DB to use as a fallback option.
We want to continue trying to access the role name via the `threadInfo` (since older clients will not have this `roleName` field), but fallback onto it if needed. The reason this should not cause a problem is
that older clients are guaranteed to have the role stored in `threadInfo` since at the moment, only `Members` and `Admins` are roles on Comm, and neither are deletable.
As for the code, the following is done:
If the client has the newest code version, show them the robotext accessing the role either through `threadInfo` or the `content` field as a fallback.
If the client does not, then we just shim the message.
Depends on D8478