docs: Rename 'send_event' to 'send_event_on_commit'.

This commit updates the doc to rename the 'send_event' function
to 'send_ecent_on_commit'.

This is required as we no longer have the send_event function
and we prefer to use 'send_event_on_commit' in most cases and
'send_event_rollback_unsafe' in a few.

docs/subsystems/events-system.md

@@ -51,16 +51,16 @@ problems in a scalable, correct, and predictable way.
 ## Generation system
 
 Zulip's generation system is built around a Python function,
-`send_event(realm, event, users)`. It accepts the realm (used for
+`send_event_on_commit(realm, event, users)`. It accepts the realm (used for
 sharding), the event data structure (just a Python dictionary with
 some keys and value; `type` is always one of the keys but the rest
 depends on the specific event) and a list of user IDs for the users
 whose clients should receive the event. In special cases such as
 message delivery, the list of users will instead be a list of dicts
 mapping user IDs to user-specific data like whether that user was
-mentioned in that message. The data passed to `send_event` are simply
-marshalled as JSON and placed in the `notify_tornado` RabbitMQ queue
-to be consumed by the delivery system.
+mentioned in that message. The data passed to `send_event_on_commit` are
+simply marshalled as JSON and placed in the `notify_tornado` RabbitMQ
+queue to be consumed by the delivery system.
 
 Usually, this list of users is one of 3 things:
 
@@ -71,8 +71,8 @@ Usually, this list of users is one of 3 things:
   reactions, message editing, etc.); i.e. the subscribers to a channel
   or the people on a direct message thread.
 
-It is the responsibility of the caller of `send_event` to choose the
-list of user IDs correctly. There can be security problems if, for
+It is the responsibility of the caller of `send_event_on_commit` to choose
+the list of user IDs correctly. There can be security problems if, for
 example, an event containing direct message content is sent to the
 entire organization. However, if an event isn't sent to enough clients,
 there will likely be user-visible real-time sync bugs.
@@ -388,9 +388,9 @@ The final detail we need to ensure that `apply_events` always works
 correctly is to make sure that we have relevant tests for
 every event type that can be generated by Zulip. This can be tested
 manually using `test-backend --coverage BaseAction` and then
-checking that all the calls to `send_event` are covered. Someday
-we'll add automation that verifies this directly by inspecting the
-coverage data.
+checking that all the calls to `send_event_on_commit` are covered.
+Someday we'll add automation that verifies this directly by inspecting
+the coverage data.
 
 #### page_params
 

docs/subsystems/notifications.md

@@ -27,11 +27,11 @@ As a reminder, the relevant part of the flow for sending messages is
 as follows:
 
 - `do_send_messages` is the synchronous message-sending code path,
-  and passing the following data in its `send_event` call:
+  and passing the following data in its `send_event_on_commit` call:
   - Data about the message's content (e.g., mentions, wildcard
     mentions, and alert words) and encodes it into the `UserMessage`
     table's `flags` structure, which is in turn passed into
-    `send_event` for each user receiving the message.
+    `send_event_on_commit` for each user receiving the message.
   - Data about user configuration relevant to the message, such as
     `online_push_user_ids` and `stream_notify_user_ids`, are included
     in the main event dictionary.
@@ -141,8 +141,8 @@ structure of the system, when thinking about changes to it:
   details from the database like "which users receiving this message
   are online".
 - **Thousands of users**. Zulip supports thousands of users, and we
-  want to avoid `send_event()` pushing large amounts of per-user data
-  to Tornado via RabbitMQ for scalability reasons.
+  want to avoid `send_event_on_commit()` pushing large amounts of
+  per-user data to Tornado via RabbitMQ for scalability reasons.
 - **Tornado doesn't do database queries**. Because the Tornado system
   is an asynchronous event-driven framework, and our Django database
   library is synchronous, database queries are very expensive. So