bug#63651: possible eglot xref-find-references optimization

[Alan Donovan via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

Hi João & other eglot folks,

I've been doing a small amount of digging into what makes VSCode so
relatively fast. One item that I noticed is that eglot, in the loop
that it does over the references obtained from the LSP server, calls
find-buffer-visiting to avoid re-reading files that are already open
in buffers. I'm not sure whether this is just an optimization, or
whether it is necessary to ensure that modified buffer contents are
rendered correctly, but it's noticeably slow: for one large query that
results in an xref buffer of 1300 lines, the operation takes about 2s
normally, but only about 0.8s when I replace the find-buffer-visiting
call with false. (According to the elisp CPU profiler,
find-buffer-visiting calls file-truename, recursively, a lot.)

(defun eglot--xref-make-match (name uri range)
  "Like `xref-make-match' but with LSP's NAME, URI and RANGE.
Try to visit the target file for a richer summary line."
  (pcase-let*
      ((file (eglot--uri-to-path uri))
       (visiting (or (find-buffer-visiting file) ;; <--- replace this with false
                     (gethash uri eglot--temp-location-buffers)))
       (collect (lambda ()
...

Would that change be sound? Or is it necessary for the reason I
guessed at (or some other reason)?

cheers
alan