Revert "docs: Update .html links to .md."

This doesn't work without the CommonMark upgrade.

This reverts commit c87893feea.

docs/testing/continuous-integration.md

@@ -45,7 +45,7 @@ CI. Make sure that you have uploaded your SSH keys to GitHub: CircleCI
 uses those SSH keys for authentication.
 
 [docker-hub]: https://hub.docker.com/
-[circleci-setup]: ../git/cloning.md#step-3-configure-continuous-integration-for-your-fork
+[circleci-setup]: ../git/cloning.html#step-3-configure-continuous-integration-for-your-fork
 [circleci-ssh]: https://circleci.com/docs/2.0/ssh-access-jobs/
 
 ### Suites
@@ -177,7 +177,7 @@ our configuration, you'll want to look at these closely.
   that every remote branch you push will be tested, which can be
   helpful when debugging something complicated.
 
-[travis-fork]: ../git/cloning.md#step-3-configure-continuous-integration-for-your-fork
+[travis-fork]: ../git/cloning.html#step-3-configure-continuous-integration-for-your-fork
 
 ### Performance optimizations
 

docs/testing/linters.md

@@ -11,7 +11,7 @@ but for other files, we are quite thorough about checking semantic
 correctness.
 
 Obviously, a large reason for linting code is to enforce the [Zulip
-coding standards](../contributing/code-style.md).  But we also use the linters to
+coding standards](../contributing/code-style.html).  But we also use the linters to
 prevent common coding errors.
 
 We borrow some open source tools for much of our linting, and the links
@@ -63,7 +63,7 @@ the other lint checks.
 
 ## General considerations
 
-Once you have read the [Zulip coding guidelines](../contributing/code-style.md), you can
+Once you have read the [Zulip coding guidelines](../contributing/code-style.html), you can
 be pretty confident that 99% of the code that you write will pass through
 the linters fine, as long as you are thorough about keeping your code clean.
 And, of course, for minor oversights, `lint` is your friend, not your foe.
@@ -75,7 +75,7 @@ extreme cases, but often it can be a simple matter of writing your code
 in a slightly different style to appease the linter.  If you have
 problems getting something to lint, you can submit an unfinished PR
 and ask the reviewer to help you work through the lint problem, or you
-can find other people in the [Zulip Community](../contributing/chat-zulip-org.md)
+can find other people in the [Zulip Community](../contributing/chat-zulip-org.html)
 to help you.
 
 Also, bear in mind that 100% of the lint code is open source, so if you
@@ -83,7 +83,7 @@ find limitations in either the Zulip home-grown stuff or our third party
 tools, feedback will be highly appreciated.
 
 Finally, one way to clean up your code is to thoroughly exercise it
-with tests.  The [Zulip test documentation](../testing/testing.md)
+with tests.  The [Zulip test documentation](../testing/testing.html)
 describes our test system in detail.
 
 ## Lint checks
@@ -100,7 +100,7 @@ following checks:
 - Check CSS for parsability and formatting.
 - Check JavaScript code for addClass calls.
 - Running `mypy` to check static types in Python code.  Our
-  [documentation on using mypy](../testing/mypy.md) covers mypy in
+  [documentation on using mypy](../testing/mypy.html) covers mypy in
   more detail.
 
 The rest of this document pertains to the checks that occur in `./tools/lint`.

docs/testing/testing-with-django.md

@@ -262,7 +262,7 @@ from Django as well as our own custom helpers.  Here is an example:
 
     self.assertTrue(rate_limit_mock.called)
 
-Follow [this link](../subsystems/settings.md#testing-non-default-settings) for more
+Follow [this link](../subsystems/settings.html#testing-non-default-settings) for more
 information on the "settings" context manager.
 
 A common use is to prevent a call to a third-party service from using
@@ -337,7 +337,7 @@ We use mocks and stubs for all the typical reasons:
 - to stub out calls to third-party services
 - to make it so that you can [run the Zulip tests on the airplane without wifi][no-internet]
 
-[no-internet]: testing.md#internet-access-inside-test-suites
+[no-internet]: testing.html#internet-access-inside-test-suites
 
 A detailed description of mocks, along with useful coded snippets, can be found in the section
 [Testing with mocks](#testing-with-mocks).
@@ -375,7 +375,7 @@ the same data structure as performing an action that generates said event.
 
 This is a bit esoteric, but if you read the tests, you will see some of
 the patterns.  You can also learn more about our event system in the
-[new feature tutorial](../tutorials/new-feature-tutorial.md#handle-database-interactions).
+[new feature tutorial](../tutorials/new-feature-tutorial.html#handle-database-interactions).
 
 ### Negative tests
 

docs/testing/testing.md

@@ -5,18 +5,18 @@
 Zulip has a full test suite that includes many components.  The most
 important components are documented in depth in their own sections:
 
-- [Django](../testing/testing-with-django.md): backend Python tests
-- [Casper](../testing/testing-with-casper.md): end-to-end UI tests
-- [Node](../testing/testing-with-node.md): unit tests for JS front end code
-- [Linters](../testing/linters.md): Our parallel linter suite
-- [CI details](continuous-integration.md): How all of these run in CI
+- [Django](../testing/testing-with-django.html): backend Python tests
+- [Casper](../testing/testing-with-casper.html): end-to-end UI tests
+- [Node](../testing/testing-with-node.html): unit tests for JS front end code
+- [Linters](../testing/linters.html): Our parallel linter suite
+- [CI details](continuous-integration.html): How all of these run in CI
 - [Other test suites](#other-test-suites): Our various smaller test suites.
 
 This document covers more general testing issues, such as how to run the
 entire test suite, how to troubleshoot database issues, how to manually
 test the front end, etc.
 
-We also document [how to manually test the app](manual-testing.md).
+We also document [how to manually test the app](manual-testing.html).
 
 ## Running tests
 
@@ -60,7 +60,7 @@ 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
-  [schema migration documentation](../subsystems/schema-migrations.md)
+  [schema migration documentation](../subsystems/schema-migrations.html)
   for details on how to do database migrations correctly.
 - `tools/test-documentation`: Checks for broken links in this
   ReadTheDocs documentation site.
@@ -72,7 +72,7 @@ Zulip also has about a dozen smaller tests suites:
 - `test-locked-requirements`: Verifies that developers didn't forget
   to run `tools/update-locked-requirements` after modifying
   `requirements/*.in`.  See
-  [our dependency documentation](../subsystems/dependencies.md) for
+  [our dependency documentation](../subsystems/dependencies.html) for
   details on the system this is verifying.
 - `tools/check-capitalization`: Checks whether translated strings (aka
   user-facing strings) correctly follow Zulip's capitalization
@@ -181,7 +181,7 @@ This is easy to do using test fixtures (a fancy word for fixed data
 used in tests) and the `mock.patch` function to specify what HTTP
 response should be used by the tests for every outgoing HTTP (or other
 network) request.  Consult
-[our guide on mocking](../testing/testing-with-django.md#zulip-mocking-practices) to
+[our guide on mocking](../testing/testing-with-django.html#zulip-mocking-practices) to
 learn how to mock network requests easily; there are also a number of
 examples throughout the codebase.
 
@@ -246,7 +246,7 @@ it. On Ubuntu:
 
 This section is about troubleshooting your local development environment.
 
-There is a [separate manual testing doc](manual-testing.md) that
+There is a [separate manual testing doc](manual-testing.html) that
 enumerates things you can test as part of manual QA.
 
 ### Clearing the development database