Clear more data in TypeChecker.reset() instead of asserting

[svalentin]

Running mypy daemon on internal Dropbox codebase can cause an AssertionError:

version: 1.16.0+dev.ca609acabdc94ee973a53d62b8dcb7e55c789aec Daemon crashed! Traceback (most recent call last): File "mypy/dmypy_server.py", line 237, in serve File "mypy/dmypy_server.py", line 286, in run_command File "mypy/dmypy_server.py", line 364, in cmd_check File "mypy/dmypy_server.py", line 428, in check File "mypy/dmypy_server.py", line 517, in initialize_fine_grained File "mypy/server/update.py", line 265, in update File "mypy/server/update.py", line 367, in update_one File "mypy/server/update.py", line 432, in update_module File "mypy/server/update.py", line 672, in update_module_isolated File "mypy/build.py", line 2410, in finish_passes File "mypy/build.py", line 2417, in free_state File "mypy/checker.py", line 443, in reset AssertionError

Let's convert these asserts in reset() to actual cleanup. I see no reason not to clean them up.
It also seems safe for this particular crash, since in File "mypy/build.py", line 2417, in free_state
right after this line there's self._type_checker = None. So even if we wer not to call reset() everything would still be correct.

Alternatively, we can just reset everything by calling __init__ with original args:

self.__init__(self.errors, self.modules, self.options, self.tree, self.path, self.plugin, self.expr_checker.per_line_checking_time_ns)

[JukkaL]

This looks reasonable at least as a temporary fix, but the assertion failure may be a symptom of another problem, so we should investigate this in more detail before the next release.

[github-actions]

According to mypy_primer, this change doesn't affect type check results on a corpus of open source code. ✅