The Linux-only conversion of file URLs with a non-empty (other than "localhost")
authority to smb URLs had been added in 2010 with
0b9ef81b "tools-urlobj-smb-scheme-patch.diff:
migrated" (applying a Go-oo patch?) but giving no rationale beyond "process
relative SMB paths (in hyperlinks) correctly".  That makes it hard to tell
whether that patch is (still) actively useful for anything, or was just a
misguided hack from the beginning:

* Why make this Linux only?  What about other non-Windows OSs?  (On Windows,
  such URLs can be resolved as UNC pathnames.)  If the reason for Linux-only was
  that it is the only OS where LO can handle smb URLs via GIO, why not make it
  conditional on ENABLE_GIO?

* Why map to smb?  There are various remote file access protocols.  Hardcoding
  smb looks arbitrary here.

Anyway, INetURLObject is arguably at a wrong level for such a patch.  To not
drop the hack wholesale, reimplement it in the file UCP, forwarding to a
potential other UCP that can handle smb URLs any file://<host>/... URLs
(rewritten as smb URLs) that the file UCP cannot handle itself.
(file://localhost/... URLs will already have been normalized to file:///... by
INetURLObject when they reach the file UCP, and even if they were not, the
osl/file.hxx functionality underlying fileaccess::TaskManager::getUnqFromUrl
knows how to handle them, so they will not take the forward-to-smb code branch.)

(The corresponding #ifdef WIN code from 0b9ef81b
has already been removed with 82034b04
"tdf#119326 crash when adding "Windows Share" File resource".)

(I came across that 2010 patch while looking into
<https://bugs.documentfoundation.org/show_bug.cgi?id=107461> "Does not support
'file://' scheme with actual hostname".  A next step would be to make the file
UCP actually handle any file://<host>/... URLs that denote the local host.)

Change-Id: I77242705dc4c6c1e9cb3a4f32253224ac6cb13cb
Reviewed-on: https://gerrit.libreoffice.org/67372
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>