Change Details

With `RedirectingFileSystem` simplified to handling only path mapping, its old behaviour has to be implemented elsewhere. Add a new API that takes multiple overlays (buffers or paths) and maps them into an `OverlayFileSystem` taking into account the "fallthrough" and "redirecting-with" properties in the YAML overlay specifications. Note that this comes with a slight change in semantics, it is no longer possible to chain VFS mappings. Given an overlay with a mapping of A -> B and another overlay with a mapping B -> C, A will no longer map to C. A -> C must be specified as its own mapping if this is desired. Depends on D121424

Implements `redirecting-with` using an `OverlayFileSystem` rather than nesting `RedirectingFileSystem` - - "fallthrough": adds the `RedirectingFileSystem` to `OverlayFileSystem` - "fallback": adds the `RedirectingFileSystem` *before* the previously added one. This is really only useful when its the initial overlay to place it before the `RealFileSystem` - "redirect-only": removes any previously added filesystems. Mostly intended to remove the `RealFileSystem`, but works in the general case as well. Updates `getVFSFromYAML` to use this API, as well as any existing uses of `getVFSFromYAML` since it's simpler anyway (ie. no need to read the underlying buffers first). This does come with a slight change in semantics though - it is no longer possible to "chain" VFS mappings. Given an overlay with a mapping of A -> B and another with B -> C, A can no longer map to C. An A ->C mapping must be specified as its own mapping if this is desired. The intention of this change is to allow for simplifying `RedirectingFileSystem` by removing all the `redirecting-with` handling from it. This will allow reverting it back to its original implementation where it simply performed the mapping and failed if that mapping did not exist in `ExternalFS`. That will be completed in a later commit to allow for an easier migration path if any downstream user requires the ability to chain mappings. Depends on D121423

With `RImplements `redirectingFileSystem` simplified to handling only path mapping,-with` using an `OverlayFileSystem` rather than its old behaviour has to be implemented elsewherenesting `RedirectingFileSystem` - - "fallthrough": adds the `RedirectingFileSystem` to `OverlayFileSystem` - "fallback": adds the `RedirectingFileSystem` *before* the previously added one. This is really only useful when its the initial overlay to place it before the `RealFileSystem` - "redirect-only": removes any previously added filesystems. Mostly intended to remove the `RealFileSystem`, but works in the general case as well. Add a new API that takes multiple overlays (buffers or paths) and mapsUpdates `getVFSFromYAML` to use this API, as well as any existing uses them into an `OverlayFileSystem` taking into account the "fallthrough"of `getVFSFromYAML` since it's simpler anyway (ie. no need to read the and "redirecting-with" properties in the YAML overlay specificationsunderlying buffers first). This does come with a slight change in semantics though - it is no longer possible to "chain" VFS mappings. Given an overlay with a mapping of A -> B and another with B -> C, A can no longer map to C. An A ->C mapping must be specified as its own mapping if this is desired. Note that this comes with a slight change in semantics,The intention of this change is to allow for simplifying `RedirectingFileSystem` by removing all the `redirecting-with` handling from it. it is no longerThis will allow reverting it back to its original implementation where it simply performed the mapping and failed if that possible to chain VFS mappingsmapping did not exist in `ExternalFS`. Given an overlay with a mapping of A ->That will be completed in a later B and another overlay with a mapping B -> C, A will no longer map to C.commit to allow for an easier migration path if any downstream user A -> C must be specified as its owrequires the ability to chain mapping if this is desireds. Depends on D1214243