Fallback to FS cache when sqlite fails

[ilevkivskyi]

Fixes #22010
Fixes #21495
Fixes #21440

This handles 3 crash scenarios where we cannot use sqlite cache. I propose to try falling back to FS cache in case it might work. If it doesn't not work either (e.g. read-only filesystem), it already fails gracefully. Note that FS cache fails completely silently, but I think here it is better to write a short note, but still return 0 (assuming there are no type errors).

(Not adding tests because I don't like mocking)

cc @JukkaL

[ilevkivskyi]

Diff in pandas is interesting, most likely because our join is both non-commutative and non-associative, so inference for these lines

UNARY_OPS_SYMS = ("+", "-", "~", "not")
_unary_ops_funcs = (operator.pos, operator.neg, operator.invert, _logical_not)
_unary_ops_dict = dict(zip(UNARY_OPS_SYMS, _unary_ops_funcs, strict=True))

is non-deterministic.

[ilevkivskyi]

In general, join of callables is quite bad currently.

[ilevkivskyi]

@JukkaL if there are no comments, I am merging this tomorrow.

[JukkaL]

If sqlite works in the coordinator but fails in a worker, I think the worker quietly uses FS cache while the coordinator uses sqlite. Maybe we should force the worker to use the same cache mechanism as the coordinator always, and fail otherwise?

Another potential issue is that the note could be included in the junit.xml file. Also it can get stuck in mypy daemon across runs, but it should probably be only shown once.

[ilevkivskyi]

It is unlikely that it will fail in the worker if it works in coordinator, but yeah, it is better be safe here and fail loudly in such case.

Note being included in the junit.xml is fine I think. It is kind of a warning, so that if people check junit.xml being empty, they will need to either fix underlying problem, or accept it with --no-sqlite-cache.

I will double-check about the daemon, maybe we should not show this at all for the daemon, since this is only relevant for --use-fine-grained-cache, which is still relatively niche ATM (this may change when we will start using parallel workers for daemon startup).

[ilevkivskyi]

I verified we already don't try to create metastore (for real) with the daemon unless --use-fine-grained-cache is set. And when it is set, the notes are only partially sticky, i.e. they disappear as soon as something changes on (re-)check.

[github-actions]

Diff from mypy_primer, showing the effect of this PR on open source code:

scipy-stubs (https://github.com/scipy/scipy-stubs)
+ tests/misc/test_submodules_empty.pyi:3: note: See https://mypy.readthedocs.io/en/stable/running_mypy.html#missing-imports