actions: Delete zerver.lib.actions.

Signed-off-by: Anders Kaseorg <anders@zulip.com>

docs/contributing/code-style.md

@@ -155,7 +155,7 @@ object before the first thread wrote out its change.
 
 ### Using raw saves to update important model objects
 
-In most cases, we already have a function in zerver/lib/actions.py with
+In most cases, we already have a function in `zerver.actions` with
 a name like do_activate_user that will correctly handle lookups,
 caching, and notifying running browsers via the event system about your
 change. So please check whether such a function exists before writing

docs/overview/directory-structure.md

@@ -23,7 +23,7 @@ paths will be familiar to Django developers.
 
 - `zerver/lib/*.py` Most library code.
 
-- `zerver/lib/actions.py` Most code doing writes to user-facing
+- `zerver/actions/*.py` Most code doing writes to user-facing
   database tables lives here. In particular, we have a policy that
   all code calling `send_event` to trigger [pushing data to
   clients](../subsystems/events-system.md) must live here.

docs/production/management-commands.md

@@ -91,12 +91,12 @@ database, for most objects, in addition to saving the changes to the
 database, one may also need to flush caches, notify the apps and open
 browser windows, and record the change in Zulip's `RealmAuditLog`
 audit history table. For almost any data change you want to do, there
-is already a function in `zerver.lib.actions.py` with a name like
+is already a function in `zerver.actions` with a name like
 `do_change_full_name` that updates that field and notifies clients
 correctly.
 
-For convenience, Zulip automatically import `zerver/models.py` and
-`zerver/lib/actions.py` into every management shell; if you need to
+For convenience, Zulip automatically imports `zerver/models.py`
+into every management shell; if you need to
 access other functions, you'll need to import them yourself.
 
 ## Other useful manage.py commands

docs/subsystems/management-commands.md

@@ -51,7 +51,7 @@ project.
   (and ideally, also used in Zulip's existing code). Look for code in
   `zerver/lib/` that already does what you need. For most actions,
   you can just call a `do_change_foo` type function from
-  `zerver/lib/actions.py` to do all the work; this is usually far
+  `zerver/actions/` to do all the work; this is usually far
   better than manipulating the database directly, since the library
   functions used by the UI are maintained to correctly live-update the
   UI if needed.

docs/testing/testing.md

@@ -32,7 +32,7 @@ because it takes a long time. Instead, your edit/refresh cycle will
 typically involve running subsets of the tests with commands like these:
 
 ```bash
-./tools/lint zerver/lib/actions.py # Lint the file you just changed
+./tools/lint zerver/models.py # Lint the file you just changed
 ./tools/test-backend zerver.tests.test_markdown.MarkdownTest.test_inline_youtube
 ./tools/test-backend MarkdownTest # Run `test-backend --help` for more options
 ./tools/test-js-with-node util

docs/tutorials/writing-views.md

@@ -242,7 +242,7 @@ change the server more than once or cause unwanted side effects.
 ### Making changes to the database
 
 If the view does any modification to the database, that change is done
-in a helper function in `zerver/lib/actions.py`. Those functions are
+in a helper function in `zerver/actions/*.py`. Those functions are
 responsible for doing a complete update to the state of the server,
 which often entails both updating the database and sending any events
 to notify clients about the state change. When possible, we prefer to