models: Rename zerver/models.py to zerver/models/__init__.py.

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

docs/development/using.md

@@ -47,7 +47,7 @@ the development environment][authentication-dev-server].
   - The Python queue workers will also automatically restart when you
     save changes, as long as they haven't crashed (which can happen if
     they reloaded into a version with a syntax error).
-- If you change the database schema (`zerver/models.py`), you'll need
+- If you change the database schema (`zerver/models/*.py`), you'll need
   to use the [Django migrations
   process](../subsystems/schema-migrations.md); see also the [new
   feature tutorial][new-feature-tutorial] for an example.

docs/overview/directory-structure.md

@@ -17,9 +17,9 @@ paths will be familiar to Django developers.
   [Django routes file](https://docs.djangoproject.com/en/3.2/topics/http/urls/).
   Defines which URLs are handled by which view functions or templates.
 
-- `zerver/models.py` Main
+- `zerver/models/*.py`
   [Django models](https://docs.djangoproject.com/en/3.2/topics/db/models/)
-  file. Defines Zulip's database tables.
+  files. Defines Zulip's database tables.
 
 - `zerver/lib/*.py` Most library code.
 

docs/production/authentication-methods.md

@@ -365,7 +365,7 @@ You can look at the [full list of fields][models-py] in the Zulip user
 model; search for `class UserProfile`, but the above should cover all
 the fields that would be useful to sync from your LDAP databases.
 
-[models-py]: https://github.com/zulip/zulip/blob/main/zerver/models.py
+[models-py]: https://github.com/zulip/zulip/blob/main/zerver/models/__init__.py
 [django-auth-booleans]: https://django-auth-ldap.readthedocs.io/en/latest/users.html#easy-attributes
 
 ### Multiple LDAP searches

docs/production/management-commands.md

@@ -95,7 +95,7 @@ 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 imports `zerver/models.py`
+For convenience, Zulip automatically imports `zerver.models`
 into every management shell; if you need to
 access other functions, you'll need to import them yourself.
 

docs/subsystems/caching.md

@@ -131,7 +131,7 @@ you configure some code to run every time Django does something (for
 `post_save`, right after any write to the database using Django's
 `.save()`).
 
-There's a handful of lines in `zerver/models.py` like these that
+There's a handful of lines in `zerver/models/*.py` like these that
 configure this:
 
 ```python

docs/subsystems/schema-migrations.md

@@ -9,9 +9,9 @@ This page documents some important issues related to writing schema
 migrations.
 
 - If your database migration is just to reflect new fields in
-  `models.py`, you'll typically want to just:
+  `models/*.py`, you'll typically want to just:
   - Rebase your branch before you start (this may save work later).
-  - Update the model class definitions in `zerver/models.py`.
+  - Update the model class definitions in `zerver/models/*.py`.
   - Run `./manage.py makemigrations` to generate a migration file
   - Rename the migration file to have a descriptive name if Django
     generated used a date-based name like `0089_auto_20170710_1353.py`
@@ -33,7 +33,7 @@ migrations.
   - If your migrations were automatically generated using
     `manage.py makemigrations`, a good option is to just remove your
     migration and rerun the command after rebasing. Remember to
-    `git rebase` to do this in the the commit that changed `models.py`
+    `git rebase` to do this in the the commit that changed `models/*.py`
     if you have a multi-commit branch.
   - If you wrote code as part of preparing your migrations, or prefer
     this workflow, you can use run `./tools/renumber-migrations`,

docs/subsystems/typing-indicators.md

@@ -37,7 +37,7 @@ On a high level the typing indicators system works like this:
 Note that there is a user-level privacy setting to disable sending
 typing notifications that a client should check when implementing
 the "writing user" protocol below. See `send_private_typing_notifications`
-in the `UserBaseSettings` model in `zerver/models.py` and in the
+in the `UserBaseSettings` model in `zerver/models/__init__.py` and in the
 `user_settings` object in the `POST /register` response.
 
 ## Writing user

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/models.py # Lint the file you just changed
+./tools/lint zerver/models/__init__.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
@@ -60,7 +60,7 @@ eventually work with, each with its own page detailing how it works:
 Additionally, Zulip also has about a dozen smaller tests suites:
 
 - `tools/test-migrations`: Checks whether the `zerver/migrations`
-  migration content the models defined in `zerver/models.py`. See our
+  migration content the models defined in `zerver/models/*.py`. See our
   [schema migration documentation](../subsystems/schema-migrations.md)
   for details on how to do database migrations correctly.
 - `tools/test-documentation`: Checks for broken links in this

docs/tutorials/new-feature-tutorial.md

@@ -35,7 +35,7 @@ organization in Zulip). The following files are involved in the process:
 
 **Backend**
 
-- `zerver/models.py`: Defines the database model.
+- `zerver/models/__init__.py`: Defines the database model.
 - `zerver/views/realm.py`: The view function that implements the API endpoint
   for editing realm objects.
 - `zerver/actions/realm_settings.py`: Contains code for updating and interacting with the database.
@@ -73,7 +73,7 @@ organization in Zulip). The following files are involved in the process:
 ### Adding a field to the database
 
 **Update the model:** The server accesses the underlying database in
-`zerver/models.py`. Add a new field in the appropriate class.
+`zerver/models/__init__.py`. Add a new field in the appropriate class.
 
 **Create and run the migration:** To create and apply a migration, run the
 following commands:
@@ -185,10 +185,10 @@ task of requiring messages to have a topic, you can [view this commit](https://g
 
 First, update the database and model to store the new setting. Add a new
 boolean field, `mandatory_topics`, to the Realm model in
-`zerver/models.py`.
+`zerver/models/__init__.py`.
 
 ```diff
- # zerver/models.py
+ # zerver/models/__init__.py
 
  class Realm(models.Model):
      # ...
@@ -205,7 +205,7 @@ is the field's type. Add the new field to the `property_types`
 dictionary.
 
 ```diff
- # zerver/models.py
+ # zerver/models/__init__.py
 
  class Realm(models.Model)
      # ...