File access performance regression on Graviton2

Description

We observed a ~37% performance regression on AWS Graviton2 in a Python benchmark that repeatedly opens, reads, and closes the same small file. We did not detect the regression on any other platform, including Graviton3.

A bisect identified #11919 as the first bad commit. These changes included removal of a shared lock early-return path, possibly forcing reads to go through extra overhead in acquiring an exclusive lock.

Restoring the shared lock path resolved the regression on our end. We were not able to determine why this was not detected on other platforms.

	if !trunc {
		d.handleMu.RLock()
		canReuseCurHandle := (!read || d.isReadHandleOk()) && (!write || d.isWriteHandleOk())
		d.handleMu.RUnlock()
		if canReuseCurHandle {
			// Current handles are sufficient.
			return nil
		}
	}

Was removing this an intentional tradeoff or would it make sense to restore the shared lock? From my quick review, it seems separable from the issue that the PR intended to resolve.

Steps to reproduce

Run something like the following within a new and old (before the #11919) sandbox and compare execution time:

for _ in range 100000:
    with open("filename", "r") as f:
        f.read()

For some reason, we were only able to reproduce this on Graviton2

runsc version

1c9217b74ada