navigateToApp emits new value for currentAppId$ even if navigation is blocked

[flash1293]

On blocking a navigation using history.block and trying to navigate away from the current app using the navigateToApp method, the navigation is blocked as expected but currentAppId$ is updated with the target app id right away. This happens because in

kibana/src/core/public/application/application_service.tsx

Line 278 in 9d5aca5

this.currentAppId$.next(appId);

next is called on the observable without checking for navigation blocks. It can probably be fixed by removing the next call as

kibana/src/core/public/application/application_service.tsx

Lines 152 to 157 in 9d5aca5

	const wrapMount = (plugin: PluginOpaqueId, app: App<any>): AppMount => {
	return async (params) => {
	this.currentAppId$.next(app.id);
	return app.mount(params);
	};
	};

should pick it up as well. However this has to be tested because it slightly changes the timing of currentAppId$ some apps might rely on.

[elasticmachine]

Pinging @elastic/kibana-core (Team:Core)

[afharo]

Good catch @flash1293! We might need to keep an eye on how does this affect application_usage handling application changes

[lukeelmers]

This is blocking the VisEditors team in moving away from the deprecated onAppLeave, which is targeted for removal by 8.8.