Remove class-level caches from CheckpointFile

[connorjward]

Fixes #2809 (and hopefully fixes CI).

Is it appropriate to provide a test for something non-deterministic like this?

[connorjward]

@ksagiyam this is failing the backwards compatibility tests due to mismatching SFs. Rather than expunging the caches as I do here should they be stored on the instance instead of the class? I find the code quite hard to follow.

[ksagiyam]

The backward_compat tests are failing I think because I relied on the fact that meshes are cached in those tests.
Here

firedrake/tests/output/test_io_backward_compat.py

Line 112 in f13bbb5

mesh = afile.load_mesh(_generate_mesh_name(cell_type))

we end up creating multiple instances of the same mesh with the same name (say meshA and meshB, both named, e.g., "mesh_triangle"). As function spaces are cached based on "mesh_triangle" (and other names) on the CheckpointFile instance (afile), when we load a function space on meshB, which has already been loaded for meshA and cached, we end up grabbing the cached one. This causes conflict as meshA has pointSFA, the loaded function space inherits pointSFA, but meshB has poinSFB; though pointSFA and pointSFB are identical, they are different objects, which is what PETSc is complaining.

I think we can just use with CheckpointFile(..) as afile: as usual inside the for loop in the backward_compat tests.

[ksagiyam]

Thanks, Connor!

[connorjward]

Can we merge this? We are getting random fails in the link checker for the docs build which I'm certain is nothing to do with this PR.

[ksagiyam]

Unfortunately, the issue seems not resolved:

#2787
#2804

These branches have been rebased.

[connorjward]

Blast.