To not increase the size of the main org.libreoffice.LibreOffice app further,
the plan was to realize this as an org.libreoffice.LibreOffice.Help extension.
Ideally, this would be a localized extension, so that, by default, only a
relevant subset of the extension would be downloaded and installed.  (But see
below.)

There are multiple technical problems, as discussed at <https://github.com/
flathub/org.libreoffice.LibreOffice/issues/35#issuecomment-447295308> "Add
integrated LibreOffice Help offline":

* LO can't pass a file URL with query part to xdg-open, so uses a temporary
  wrapper .html file that redirects to the target URL.  But for the flatpak case
  this wrapper can't be in /tmp (which isn't visible from outside the flatpak
  sandbox), but is instead stored in a new temp dir under $XDG_CACHE_HOME (which
  is always set for flatpaks and /is/ visible form the outside) that is
  removed on LO exit.

* The file URL stored in the temp file must be rewritten from the internal path
  (/app/libreoffice/help/...) to the path as seen outside the flatpak sandbox.
  While the path for the org.libreoffice.LibreOffice /app is stored in
  /.flatpak-info, the external path for the org.libreoffice.LibreOffice.Help
  extension is different and not stored there.  So use a hack trying to
  construct that path from what information is available in /.flatpak-info.

* But the help content consists of locale-specific and shared files, and those
  reference each other with relative links.  But a localized flatpak extension
  cannot contain shared files, it can only contain per-language sub-dirs.  And
  if the shared help files were kept out of the extension, as part of the app
  itself, the relative paths among these files inside the flatpak sandbox would
  differ from those outside of it, so would be broken when viewing the content
  in the external browser.  A solution would either (a) need to somehow rewrite
  the content of all the help files being served from LO to the external
  browser, or (b) replicate the shared help files in all the extension's per-
  language sub-dirs (and if some localization uses en-US content as a fallback
  for only part of its translated content, e.g., in the case of media files,
  would need to also replicate that en-US content), or (c) use a non-localized
  extension that always contains the content for all localizations.

For now, I chose the third approach.  This makes the
org.libreoffice.LibreOffice.Help extension relatively large (the current
/app/libreoffice/help tree has a size of ca. 100MB), so that I decided to not
have it downloaded and installed automatically ("no-autodownload": true in
solenv/flatpak-manifest.in).  (I checked with Flatpak 1.0.6 that if the
extension should be changed to a localized one with the same name in the future,
updating from an older version would work.  If the old extension was not
installed, just the relevant localizations of the new version will be downloaded
and installed.  If the old extension was installed, the full set of
localizations of the new version will be downloaded and installed.)

(As also mentioned at <https://github.com/flathub/org.libreoffice.LibreOffice/
issues/35#issuecomment-447295308>:  "A second, minor, nuisance is that, for
security reasons, an `xdg-open file:///...html` call from a flatpak leads to an
intermediate popup dialog letting the user chose which application to use to
open the URI, while e.g. an `xdg-open http:///...html` is allowed to go directly
to the user's preferred browser.  So accessing help content from LO flatpak
would present that popup dialog first, forcing the user to select a browser to
proceed.")

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