feat: ability to reset allowed/forbidden fs scope paths, closes #7366

[LacombeJ]

What kind of change does this PR introduce?

• Bugfix
• Feature
• Docs
• New Binding issue #___
• Code style update
• Refactor
• Build-related changes
• Other, please describe:

Does this PR introduce a breaking change?

• Yes, and the changes were approved in issue #___
• No

Checklist

• When resolving issues, they are referenced in the PR's title (e.g fix: remove a typo, closes #___, #___)
• A change file is added if any packages will require a version bump due to this PR per the instructions in the readme.
• I have added a convincing reason for adding this feature, if necessary

Other information

Issue: #7366

[amrbashir]

Thank you

[amrbashir]

uh I should've noticed this earlier, @LacombeJ could you rebase this PR to target 1.x branch instead?

[LacombeJ]

uh I should've noticed this earlier, @LacombeJ could you rebase this PR to target 1.x branch instead?

Yeah sure, I was actually going to ask about that

[LacombeJ]

@amrbashir Let me know if I rebased properly.

This reset signature takes two arguments because 1.x has two possible scopes unlike dev/2.0.

pub fn reset<R: crate::Runtime>(&self, &App<R>, scope: &FsAllowlistScope) -> crate::Result<()> 

scope.reset(&app, &app.config().tauri.allowlist.fs.scope).unwrap();
scope.reset(&app, &app.config().tauri.allowlist.protocol.asset_scope).unwrap();

[lucasfernog]

Now I see it's kinda hard to use the ResetScope values so we could actually add a function that pulls a ResetScope and readds the patterns to the Scope.

[lucasfernog]

This now just needs an approval from the security team.