FIX: don't use op.realpath when reading raw

[drammock]

closes #9221

This one-line fix is almost certainly too simplistic and will probably break something, so I'm hoping for some intense scrutiny here. Here's my understanding of the problem and solution(?):

1. datalad uses git-annex to manage large data files (datalad is the recommended access method for OpenNeuro, so it's really something we should support)
2. for split raw files, this poses a problem because when the first raw is loaded, we call os.path.realpath() on the filename, so something like sub-01/ses-day1/meg/sub-01_ses-day1_task-AVLearn_run-01_part-01_meg.fif becomes /home/user/Desktop/test-datalad/ds002598/.git/annex/objects/Xz/5P/MD5E-s2146079382--dca9c1e4ee05b6b32bdcd4b5aef8c9bb.fif/MD5E-s2146079382--dca9c1e4ee05b6b32bdcd4b5aef8c9bb.fif
3. that works fine for singleton raw files, but for split files, we determine whether it's split based on the original fname, but then go looking for the subsequent parts based on the realpath-transformed fname.

my solution is to just not call realpath(). Doing so doesn't seem to hurt much as far as I can tell; I can still load sample data, and after creating a symlink on my desktop to a random .fif file on another drive, passing the symlink into read_raw() loads it just fine.

The only case I can think of where this will break something that previously worked, is if you had this:

$ tree bar
bar
├── foo
│   ├── qux_part-01_meg.fif
│   └── qux_part-02_meg.fif
└── qux_part-01_meg.fif -> foo/qux_part-01_meg.fif

...and you tried to load the symlink in bar. This would fail because now we would look for ...part-02... in bar/ instead of in bar/foo/. But honestly that seems like an edge case that we shouldn't support anyway --- allowing users to access all parts of a split raw by providing a symlink to just the first part (when symlinks to the other parts aren't also present).

[agramfort]

I think it’s the right fix

[drammock]

@agramfort any idea why realpath was there in the first place?

[cbrnr]

This looks correct. I agree that all parts of a file need to be in the same folder, symlink or not. I don't see the reason why we resolved symlinks previously, this shouldn't be necessary at all.

[agramfort]

This looks correct. I agree that all parts of a file need to be in the same folder, symlink or not. I don't see the reason why we resolved symlinks previously, this shouldn't be necessary at all.

agreed. Sorry no I don't remember. Maybe @larsoner knows.

[agramfort]

@larsoner I let you merge if happy

[larsoner]

Added a regression test for the linked issue, then added a general io test for the chdir case I mentioned. It exposed problems in many readers, so I fixed those, too, by making more uniform use of _check_fname, which always returns an abspath now.

[agramfort]

CIs complain

[larsoner]

Failure is just a timeout, feel free to merge if you're happy @agramfort