Can remove read only flag rom broadcast room, but can't reapply it

Description:

When you remove the read only flag fro a broadcast room it becomes writeable for everyone. After that it's not possible to set is to read only again

Steps to reproduce:

1. Create a channel and set it to "broadcast"
2. Go to the admin panel -> rooms -> the room you just created
3. uncheck "read only" and save
4. check "read only" again and save

Expected behavior:

either

• make the room read only again or
• make it impossible to remove the "read only" flag in the first place as a broadcast channel where everyone can write is kinda nonsense

Actual behavior:

You get Editing readOnly/reactWhenReadOnly are not allowed for broadcast rooms [error-action-not-allowed] and the room stays writeable. In fact it's not possible to set it back to the permissions it had right after creating it.

Server Setup Information:

• Version of Rocket.Chat Server: 4.0.3
• Operating System: Ubuntu Server 18.04
• Deployment Method: Docker
• Number of Running Instances: 1
• DB Replicaset Oplog: wiredTiger (oplog Enabled)
• NodeJS Version: v12.22.1
• MongoDB Version: 4.2.17

Client Setup Information

• Desktop App or Browser Version: Windows App
• Operating System: Windows 10

Additional context

Relevant logs:

Browser:

POST | https://chat.example.com/api/v1/rooms.saveRoomSettings

Status: 400 Bad Request
Version: HTTP/2
Übertragen: 841 B (228 B Größe)
Referrer Policy: same-origin

HTTP/2 400 Bad Request
access-control-allow-headers: Origin, X-Requested-With, Content-Type, Accept, X-User-Id, X-Auth-Token
access-control-allow-origin: *
cache-control: no-store
content-encoding: gzip
content-security-policy: default-src 'self' ; connect-src *; font-src 'self'  data:; frame-src *; img-src * data:; media-src * data:; script-src 'self' 'unsafe-eval' ; style-src 'self' 'unsafe-inline'
content-type: application/json
date: Tue, 19 Oct 2021 11:20:48 GMT
pragma: no-cache
server: Caddy
vary: Accept-Encoding
x-content-type-options: nosniff
x-frame-options: sameorigin
x-instance-id: EZSjP8NPPHoLj8kF8
x-xss-protection: 1
X-Firefox-Spdy: h2

POST /api/v1/rooms.saveRoomSettings HTTP/2
Host: chat.example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:93.0) Gecko/20100101 Firefox/93.0
Accept: */*
Accept-Language: de,en-US;q=0.7,en;q=0.3
Accept-Encoding: gzip, deflate, br
Referer: https://chat.example.com/admin/rooms/edit/gYs4javY9SPwBeA7D
Content-Type: application/json
X-User-Id: 75gj5yGkWLmEpY8Z9
X-Auth-Token: 02Kmxrf8BNMCFY1GZif14WYj1VdNkRmkRbiBJwCAOID
X-Requested-With: XMLHttpRequest
Content-Length: 225
Origin: https://chat.example.com
DNT: 1
Connection: keep-alive
Cookie: rc_uid=75gj5yGkWLmEpY8Z9; rc_token=02Kmxrf8BNMCFY1GZif14WYj1VdNkRmkRbiBJwCAOID
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: same-origin

Server:
none

Start with the admin Rooms edit flow and the rooms.saveRoomSettings endpoint described in the reproduction steps. Reproduce the broadcast-room setting changes and trace the reported error, then verify that the chosen expected behavior works without preventing normal room updates.