Avoiding E2E room status checks in unencrypted rooms?

### Your use case

In https://github.com/element-hq/element-web/issues/29789 I mentioned a performance issue related to checking the verification in Element. At the time I did not notice, but the issue is correlated with room size: in a large room, more time will be spent doing room verification (in my case, starts being noticeable at around 500 users, but this of course depends on hardware and is linear in room size. This runs in a background thread, so responsiveness is not impacted, but it takes more and more CPU time when "first opening" a large room.). This is a fine tradeoff for encrypted rooms, but there is a large UX impact for large unencrypted rooms, as for each user their verification status is computed between JS -> WASM -> Rust -> IndexedDB (on the web target, as seen in [ShieldUtils.ts](https://github.com/element-hq/element-web/blob/v1.11.110/src/utils/ShieldUtils.ts#L34)), so in fact is quite visible on a profiler graph when it does happen.

In some cases, this status is computed but remains unused, for example in [RoomHeader.tsx](https://github.com/element-hq/element-web/blob/v1.11.110/src/components/views/rooms/RoomHeader/RoomHeader.tsx#L103) where it is computed but only needed in DM rooms. (There are mitigations, like [throttle and useMemo](https://github.com/element-hq/element-web/blob/v1.11.110/src/hooks/useEncryptionStatus.ts#L22), but they mostly help only after this large computation is already queued/done).

Would it make sense to avoid this when the room is unencrypted somehow? For me, unverified users in an unencrypted room are not a concern, though I understand there might be reasons to have the option, for example in an invite-only homeserver restricted room (so a preference setting would work too).

### Have you considered any alternatives?

Another option, rather than a preference to skip computing room-based verification status, would be looking at adjusting the mitigations (like memoisation and throttling), though this would not really help in the cold-start case.

Another way to reduce the cost as well is creating a batched API, where user identity is loaded for multiple users, but this would need a deep API change throughout element-web's dependencies, whereas a preference can be done without any downstream changes.

### Additional context

As a side note, a similar case would apply to an encrypted public room, but I've focused on unencrypted rooms since larger rooms that are either public or encrypted are generally of that type (at least in public Matrix spaces). The same preference could apply to public rooms as well.