[BUG] users.update REST API endpoint is inconsistent on user deactivate and depends on user's chats ownership

Description:

I'm using REST API scripts to get userId and deactivate user in a moment when that user is disabled in Active Directory
I see that result of scripts using REST API is inconsistent - some users get deactivated without any issues, but sometimes script finishes with 400 error:

[2020.08.31 05:38:36][Error] Error: The remote server returned an error: (400) Bad Request.
[2020.08.31 05:38:36][Info] RC_UserID : System.Net.WebException: The remote server returned an error: (400) Bad Request.
at Microsoft.PowerShell.Commands.WebRequestPSCmdlet.GetResponse(WebRequest request)
at Microsoft.PowerShell.Commands.WebRequestPSCmdlet.ProcessRecord()

I try to deactivate user, that get error in script - and I successfully deactivated him in Admin UI

Steps to reproduce:

1. Try to deactivate user via REST API
2. Get 400 error sometimes

Expected behavior:

Consistent working of deactivate script

Actual behavior:

Some REST API deactivations stops with 400 error

Server Setup Information:

• Version of Rocket.Chat Server: 3.6.3
• Operating System: CentOS7
• Deployment Method: docker
• Number of Running Instances: 25
• DB Replicaset Oplog: Enabled
• NodeJS Version: 12.16.1
• MongoDB Version:4.0.17

Client Setup Information

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

Additional context

I see this now on 3.6.3 server version, but we checked logs, and see that it was on 3.1.1 before upgrade
Account which token used in scripts has Admin role in Rocket Chat

Relevant logs:

[2020.08.31 05:38:36][Error] Error: The remote server returned an error: (400) Bad Request.
[2020.08.31 05:38:36][Info] RC_UserID : System.Net.WebException: The remote server returned an error: (400) Bad Request.
at Microsoft.PowerShell.Commands.WebRequestPSCmdlet.GetResponse(WebRequest request)
at Microsoft.PowerShell.Commands.WebRequestPSCmdlet.ProcessRecord()

Start with the users.update REST API endpoint and reproduce deactivation for users with different chat-ownership states, recording the request and 400 response. Compare that path with the Admin UI deactivation flow; done means the endpoint handles each state consistently and its behavior is covered by the relevant API tests.