feat: added kill switch

[Marc-Antoine-Soucy]

GitHub Issue: #

Proposed Changes

• Bug fix
• Feature
• Code style update (formatting)
• Refactoring (no functional changes, no api changes)
• Build or CI related changes
• Documentation content changes
• Other, please describe:

Description

Impact on version

• Major
  • The template structure was changed.
• Minor
  • New functionalities were added.
• Patch
  • A bug in behavior was fixed.
  • Documentation was changed.

PR Checklist

Always applicable

No matter your changes, these checks always apply.

• Your conventional commits are aligned with the Impact on version section.
• Updated CHANGELOG.md.
  • Use the latest Major.Minor.X header if you do a Patch change.
  • Create a new Major.Minor.X header if you do a Minor or Major change.
  • If you create a new header, it aligns with the Impact on version section and matches what is generated in the build pipeline.
• Documentation files were updated according with the changes.
  • Update README.md and TemplateConfig.md if you made changes to templating.
  • Update AzurePipelines.md and APP_README.md if you made changes to pipelines.
  • Update Diagnostics.md if you made changes to diagnostic tools.
  • Update Architecture.md and its diagrams if you made architecture decisions or if you introduced new recipes.
  • ...and so forth: Make sure you update the documentation files associated to the recipes you changed. Review the topics by looking at the content of the doc/ folder.
• Images about the template are referenced from the wiki and added as images in this git.
• TODO comments are hints for next steps for users of the template and not planned work.

Contextual

Based on your changes these checks may not apply.

• Automated tests for the changes have been added/updated.
• Tested on all relevant platforms

Other information

Internal Issue (If applicable):

[Marc-Antoine-Soucy]

Wondering if using this pattern would be better? This would make 100% everything worked.

	var timeoutTask = Task.Delay(5000);

	// Waits for the navigation to be completed, we need the StartWith in case the navigation already finished before we started observing.
	var navTask = sectionNavigator.ObserveCurrentState()
		.Where(x => x.LastRequestState != NavigatorRequestState.Processing
			// This sometimes takes longer, so we need to need to make sure 
			&& x.GetCurrentOrNextViewModelType() != typeof(KillSwitchPageViewModel))
		// The CancellationToken is so that this returns a task.
		.FirstAsync(CancellationToken.None);

	await Task.WhenAny(navTask, timeoutTask);

[jeanplevesque]

Wondering if using this pattern would be better? This would make 100% everything worked.

	var timeoutTask = Task.Delay(5000);

	// Waits for the navigation to be completed, we need the StartWith in case the navigation already finished before we started observing.
	var navTask = sectionNavigator.ObserveCurrentState()
		.Where(x => x.LastRequestState != NavigatorRequestState.Processing
			// This sometimes takes longer, so we need to need to make sure 
			&& x.GetCurrentOrNextViewModelType() != typeof(KillSwitchPageViewModel))
		// The CancellationToken is so that this returns a task.
		.FirstAsync(CancellationToken.None);

	await Task.WhenAny(navTask, timeoutTask);

In which context?

[Marc-Antoine-Soucy]

Wondering if using this pattern would be better? This would make 100% everything worked.

	var timeoutTask = Task.Delay(5000);

	// Waits for the navigation to be completed, we need the StartWith in case the navigation already finished before we started observing.
	var navTask = sectionNavigator.ObserveCurrentState()
		.Where(x => x.LastRequestState != NavigatorRequestState.Processing
			// This sometimes takes longer, so we need to need to make sure 
			&& x.GetCurrentOrNextViewModelType() != typeof(KillSwitchPageViewModel))
		// The CancellationToken is so that this returns a task.
		.FirstAsync(CancellationToken.None);

	await Task.WhenAny(navTask, timeoutTask);

In which context?

Sometimes I have to use a "StartWith", because the navigation is already over when I get there, sometimes I need to not have a startWith, otherwise I will still be in the old viewmodel and the navigation has not started yet, this happens when I start the initial navigationflow. But the thing is, Whether I need a startwith or not is all due to the speed at which the navigation starts, which I'm not 100% is completely consistent? But I do know if I used the pattern I proposed earlier, I would 100% get an error if the test was meant to fail, and I the test would 100% work if the test was not meant to fail.

[Marc-Antoine-Soucy]

Wondering if using this pattern would be better? This would make 100% everything worked.

	var timeoutTask = Task.Delay(5000);

	// Waits for the navigation to be completed, we need the StartWith in case the navigation already finished before we started observing.
	var navTask = sectionNavigator.ObserveCurrentState()
		.Where(x => x.LastRequestState != NavigatorRequestState.Processing
			// This sometimes takes longer, so we need to need to make sure 
			&& x.GetCurrentOrNextViewModelType() != typeof(KillSwitchPageViewModel))
		// The CancellationToken is so that this returns a task.
		.FirstAsync(CancellationToken.None);

	await Task.WhenAny(navTask, timeoutTask);

In which context?

Like right now, I have a test failing in the ForceUpdatesShould despite not changing anything related to that test, and the test is ok if I add a task.delay

So, I think I'm just going to do that. Otherwise, it might just fail randomly sometimes.

[Soap-141]

After fixing JP's comment I think it looks good! Good job!