As a library or tool developer who is familiar with the MediaWiki Action API, I want to specify the bot flag with all automated requests to the REST API, so that the server can automatically mark them as automated if the user has the required permission, without me having to check the permission myself.

Problem:
The Wikibase REST API bot parameter apparently behaves differently from that of the Action API: if you include "bot": true in your request body without having the bot right, you get a HTTP 403 error.

{"code":"permission-denied","message":"Access to resource is denied","context":{"denial_reason":"unauthorized-bot-edit"}}

(AFAICT the error message actually used to be more informative, but T372999 changed it from “Unauthorized bot edit” to “Access to resource is denied”. Now only the context tells you that it’s even related to the bot parameter.)
As far as I can tell, this meaning of the bot parameter is not documented in the OpenAPI spec nor on Wikidata:REST API.

List of steps to reproduce (step by step, including full links if applicable):

• Use an account that doesn’t have the “bot” right.
• Authenticate yourself with the REST API, e.g. using an OAuth 2 owner-only client.
• Send e.g. a DELETE request to https://www.wikidata.beta.wmcloud.org/w/rest.php/wikibase/v1/entities/items/Q633996/labels/de with a body including {"bot": true}.

I noticed this issue while working on T411325, in the commit Add deleteForJson(), deleteForText(), deleteForHtml() functions.

Describe the impact that solving this problem will have on users:
Tool authors will easily be able to mark requests as automated where appropriate. Whether a request is automated or not is often an inherent property of the tool that is used to make the request; consequently, it’s convenient if the tool can simply mark the request as automated regardless of user permissions, and trust the server side to either apply the bot flag or silently drop it, rather than the tool having to first check if the user has sufficient permission to use the bot flag or not.

Describe the implications/cost of not doing this request:
Some tools just won’t bother to send the bot flag at all, treating all edits as manual even when they’re really automated and the user has the permission to mark them as such. For instance, AFAICT QuickStatements v3 always sends bot=false.

Acceptance criteria:

• The current error message will be removed
• The feature as described above will be implemented i.e., requests containing bot=True for a non-bot account will not get an error but will go through and not be marked as a bot edit
• Propose change to Quickstatements 3.0 to set bot=True as default
• Update docs if necessary

Task breakdown notes:

• Remove the bot check middleware
• adjust EntityUpdater to not throw an exception when the user sent the bot flag but doesn't have the corresponding permission
• change the $editEntity->attemptSave() call to only mark the edit as a bot edit if the bot flag was sent AND the user has bot permissions