chore: update arpack to arpack-ng 3.9.1

[szhorvat]

@krlmlr You asked to update ARPACK to the latest ARPACK-NG. This PR attempts to do that. It was quite painful: first we need to rename functions to have an igraph prefix, and avoid conflicts. This can be done automatically. But then the line lengths exceed 72 characters, which is the maximum for fixed-form Fortran, and we need to manually reformat them, with the appropriate continuation character. I hope I didn't mess this up.

The changes to snapshots are fine. But there's a failure with spectral clustering, and it's unclear to me whether that's a real failure or not. I'll have another look at this when teaching is over (mid-November).

[aviator-app]

Current Aviator status

Aviator will automatically update this comment as the status of the PR changes.
Comment /aviator refresh to force Aviator to re-examine your PR (or learn about other /aviator commands).

This pull request is currently open (not queued).

How to merge

To merge this PR, comment /aviator merge or add the mergequeue label.

---

See the real-time status of this PR on the Aviator webapp.

Use the Aviator Chrome Extension to see the status of your PR within GitHub.

[szhorvat]

@krlmlr I am quite certain that this is better than the old version, despite the test failures. That said, the tests need to be dealt with carefully before going ahead, and I won't have time for this before 2.2.0.

However, running revdepchecks for this would be quite useful, to test if anything in the real world was actually broken by this change. I'm not sure if that's possible before fixing our tests @krlmlr .

[krlmlr]

Running revdepchecks now.

[krlmlr]

The results don't look terrible, comparing with the main branch now.

[krlmlr]

Are you okay with merging this, assuming we can fix the tests?

[schochastics]

Are you okay with merging this, assuming we can fix the tests?

Just checked locally. The error occurs at random. Need to have a closer look , but I think it should be fine to merge?

[szhorvat]

I think it's best if I have a look at this first, and see if the parameters with which ARPACK is called need to be tuned. I'll also need to repro the issue in the C core.

Let's delay merging this to the next release, or maybe I can get to it on the weekend.

Thanks for running the revdepchecks, this was very useful! On a first skim, I see nothing ARPACK-related, which is indeed good.