We can have two kinds of filename in /overrides: either the symbolic link points to a path that is already going to be in the container, like /run/host/… or /usr/…, or it points to a path that is only in the container if we explicitly ask the FlatpakExports object to share it, like /home/….
For the paths that are already set up for the container, it's both misleading and useless to go through the motions of asking FlatpakExports to share it. It's misleading because it looks for a container-side filename in an environment that probably won't have it, like /usr/lib/x86_64-linux-gnu/… on a Fedora system that only has /usr/lib64, and even if we do find it, it's not the version of that file that we want to use. It's also useless because even if we do find the desired filename on the host, FlatpakExports will refuse to export paths below a prefix such as /usr that is controlled by the runtime.
A secondary benefit of this change is that it results in summarizing the contents of /overrides in a debug-level log, which is useful for situations like https://github.com/ValveSoftware/Dota-2/issues/2392 where we suspect that those contents might be wrong.
... 21:10:30.631159: pressure-vessel-wrap: D: overrides/lib/x86_64-linux-gnu/libcap.so.2 points to container-side path /run/host/usr/lib64/libcap.so.2.48 21:10:30.631184: pressure-vessel-wrap: D: overrides/lib/x86_64-linux-gnu/libpcre2-8.so.0 points to container-side path /run/host/usr/lib64/libpcre2-8.so.0.11.2 21:10:30.631230: pressure-vessel-wrap: D: Exporting /home/desktop/.local/share/Steam/ubuntu12_64/libVkLayer_steam_fossilize.so because overrides/lib/x86_64-linux-gnu/vulkan_imp_layer/1/libVkLayer_steam_fossilize.so points to it 21:10:30.631251: pressure-vessel-wrap: D: Trying to export read-only: /home/desktop/.local/share/Steam/ubuntu12_64/libVkLayer_steam_fossilize.so 21:10:30.657009: pressure-vessel-wrap: D: /home is not a symlink 21:10:30.657069: pressure-vessel-wrap: D: /home/desktop is not a symlink ...