Repository: electron
Issue: Windows Toast notifications activation issues
Labels: enhancement :sparkles:,platform/windows

<!--  As an open source project with a dedicated but small maintainer team, it can sometimes take a long time for issues to be addressed so please be patient and we will get back to you as soon as we can.
-->

### Preflight Checklist
<!-- Please ensure you've completed the following steps by replacing [ ] with [x]-->

* [x] I have read the [Contributing Guidelines](https://github.com/electron/electron/blob/master/CONTRIBUTING.md) for this project.
* [x] I agree to follow the [Code of Conduct](https://github.com/electron/electron/blob/master/CODE_OF_CONDUCT.md) that this project adheres to.
* [x] I have searched the issue tracker for a feature request that matches the one I want to file, without success.

### Problem Description
<!-- Is your feature request related to a problem? Please add a clear and concise description of what the problem is. -->

The way toast notifications support is implemented on Windows doesn't feel quite right. 
The main issue I see is that it doesn't integrate well with Windows Action Center.
I can highlight the following Action Center integration issues:
1. Once notification is displayed and moves to the Action Center, click events are not delivered to the app.
2. Notifications don't persist in the Action Center. If you open the Action Center once notification is displayed, you'll see the notification there, but the next time you open it - you'll see that notification is missing. 
3. App can't be activated from the Action Center, i.e. when notification is clicked app window is not being brought to the foreground, and when app isn't running you can't start it by clicking on notification.

There are several issues which mention the problems I described above:
#20415 
#21610

There were more issues closed as they were reported on an older electron versions.

All this makes the app which uses electron toast notifications feel broken.
I know that some people use userland packages like [electron-windows-notifications](https://github.com/felixrieseberg/electron-windows-notifications) and [electron-windows-interactive-notifications](https://github.com/felixrieseberg/electron-windows-interactive-notifications) as they implement full support of toasts on Windows.

I looked in the code which implements toast notifications on Windows here:
https://github.com/electron/electron/blob/master/shell/browser/notifications/win/windows_toast_notification.cc

I see that it doesn't implement COM Activator. 
Besides that the way activation callback is registered, is going to work only when the process is running, it can't start the process from notification click.

### Proposed Solution
<!-- Describe the solution you'd like in a clear and concise manner -->

There are a few examples from Microsoft which mention how to implement that correctly:
https://docs.microsoft.com/en-us/windows/uwp/design/shell/tiles-and-notifications/send-local-toast-desktop
https://docs.microsoft.com/en-us/windows/uwp/design/shell/tiles-and-notifications/send-local-toast-desktop-cpp-wrl

I propose to implement COM activator and expose APIs for activator registration in Windows registry and configuring app shortcut with activator GUID. It might also be required to update toast XML with `launch` property of `toast` element.
Also, it will be required to update [electron-squirrel-startup](https://www.npmjs.com/package/electron-squirrel-startup) and [electron-winstaller](https://www.npmjs.com/package/electron-winstaller) packages to automatically handle registration mentioned above.

On a related note, I think it would also be good to allow specifying user data string, which will be attached to toast XML and can be passed back along with `click` event.

As I have prior experience with toast notifications implementation in another app on C++, I would like to implement a Pull Request for that

### Alternatives Considered
<!-- A clear and concise description of any alternative solutions or features you've considered. -->

As an alternative it's also possible to implement activation using `protocol` activation type. 
This way it will be required to register custom protocol handler which will be used to activate the app, but COM components registration stuff won't be required. 

### Additional Information
<!-- Add any other context about the problem here. -->

I would highly appreciate any feedback from other electron contributors before I start working on the PR for that: opinions on the solution proposed, thoughts about complications of installation process.
Also would be good to understand the reasoning behind implementation of notification support this way instead of implementing COM activator or protocol activation.