Bug: Users can override the `crate` keyword as a DRP name

[LesterEvSe]

Project version

master (unreleased)

Project

driver

What happened?

Currently, because users can interact directly with the DependencyMap API in SimplicityHL, they can manually set the crate keyword to any path they want. This happens because the insert method allows adding the crate alias without throwing any validation errors.

Fix Suggestion

There are two potential ways to solve this problem:

1. Add validation checks inside the insert method to explicitly forbid using the crate keyword.
2. Make the insert method inside the DependencyMap struct private to external crates. Instead, implement the From<Vec<Remapping>> trait to handle conversions and perform all necessary validations at that stage.

Minimal reproduction steps

Using SDK, if you insert a mapping like the one below, it will be accepted by the compiler without any errors:

DependencyMap {
    inner: [
        Remapping {
            context_prefix: CanonPath(
                "/home/user/SimplicityHL/program",
            ),
            drp_name: "crate",
            target: CanonPath(
                "/home/user/another-dir/",
            ),
        },
    ],
}

[KyrylR]

ACK concept, though ideally, the final public API should look conceptually like this:

DependencyMap::from_entry_and_deps(
    entry: CanonSourceFile,
    deps: Vec<DepSpec>,
) -> Result<DependencyMap, ResolutionError>

So basically we are replacing raw DependencyMap construction with a validated DependencyMapBuilder

The builder should internally add the entry crate root, add dependency crate roots, validate aliases, reject duplicates, reject or explicitly model nested roots, and only then return an immutable map

[KyrylR]

I believe we should be more explicit with how we do local imports

i.e. having some sort of invariant:

Every source file belongs to exactly one package root, and crate:: always resolves to that package root.

[KyrylR]

For builder, so far I can list following validations:

- entry source must be canonical and non-anonymous
- every dependency target must be a canonical directory
- every context prefix must be a canonical directory
- alias must be a valid dependency identifier
- alias must not be crate/self/super/keyword
- duplicate context+alias remappings rejected
- overlapping crate roots rejected (?) or explicitly modeled
- resolved files must remain inside their package root

[KyrylR]

There is another problem, that is adjacent to the issue (also related to current state of #312)

e.g.

/// A dependency package should not be able to expose a symlinked source file
/// whose canonical path escapes the dependency root.
#[cfg(unix)]
#[test]
fn test_dependency_symlink_escape_rejected() {
    let ws = TempWorkspace::new("dependency_symlink_escape");

    let workspace_dir = canon(&ws.create_dir("workspace"));
    let dependency_dir_path = ws.create_dir("deps/package");
    let escaped_file = ws.create_file("outside/foo.simf", "");
    std::os::unix::fs::symlink(&escaped_file, dependency_dir_path.join("foo.simf")).unwrap();

    let dependency_dir = canon(&dependency_dir_path);
    let current_file = canon(&ws.create_file("workspace/main.simf", ""));

    let mappings = vec![Remapping {
        context_prefix: workspace_dir.clone(),
        drp_name: "dep".to_string(),
        target: dependency_dir.clone(),
    }];
    let mut map = DependencyMap::try_from(mappings).unwrap();
    map.add_crate_root(workspace_dir);
    map.add_crate_root(dependency_dir);

    let use_decl = create_dummy_use_decl(&["dep", "foo"]);
    map.resolve_path(&current_file, &use_decl)
        .expect_err("dependency symlink escape was accepted");
}

The problem is that actual file is outside the workdir, maybe in future we can accept it, rn I believe we should reject such cases