Inserting seccomp notify filter in WSL kernel 5.15.83.1 fails with EBUSY

Nobody has claimed this yet.

### Version

Microsoft Windows [Version 10.0.22621.1245]

### WSL Version

- [X] WSL 2
- [ ] WSL 1

### Kernel Version

5.15.83.1-microsoft-standard-WSL2

### Distro Version

Ubuntu 22.04

### Other Software

_No response_

### Repro Steps

Starting with WSL kernel 5.15.83.1, there is an issue inserting seccomp filters that have the "notify" action (see SECCOMP_FILTER_FLAG_NEW_LISTENER in the [Linux seccomp man page](https://man7.org/linux/man-pages/man2/seccomp.2.html)). Inserting such filters returns EBUSY from the kernel.

Possible cause is that PID 1 in the WSL distro appears to have a seccomp filter attached to it by default:

```
wsl -d Ubuntu-22.04

$ grep -i seccomp /proc/1/status
Seccomp: 2
Seccomp_filters: 1 <<< HERE
```

I believe the presence of this filter on PID 1 is causing the problem: the filter is inherited by all child processes in the distro, and therefore a child process that tries to insert a seccomp notify filter (SECCOMP_FILTER_FLAG_NEW_LISTENER) gets an EBUSY response from the kernel since only one such filter per process is allowed.

The problem does NOT occur in WSL kernel 5.15.79.1. In that kernel, PID 1 has no seccomp filter on it (as expected):

```
$ grep -i seccomp /proc/1/status
Seccomp: 0
Seccomp_filters: 0
```

### Expected Behavior

A process running in a WSL Linux distro should be able to insert a seccomp notify filter (SECCOMP_FILTER_FLAG_NEW_LISTENER) without problem.

In addition, PID 1 in the WSL Linux distro should not have a seccomp filter attached to it by default.

### Actual Behavior

Starting with WSL kernel 5.15.83.1, inserting seccomp filters that have the "notify" action (SECCOMP_FILTER_FLAG_NEW_LISTENER) returns EBUSY from the kernel.

PID 1 in the WSL distro has an unexpected seccomp filter attached to it by default:

```
wsl -d Ubuntu-22.04

$ grep -i seccomp /proc/1/status
Seccomp: 2
Seccomp_filters: 1 <<< HERE
```

### Diagnostic Logs

_No response_

Start by reproducing the issue on WSL kernel 5.15.83.1 with Ubuntu 22.04 and compare /proc/1/status against kernel 5.15.79.1. Investigate the seccomp filter inherited by PID 1 and the SECCOMP_FILTER_FLAG_NEW_LISTENER path; done means seccomp notify filters no longer return EBUSY and PID 1 has no unexpected filter.

Written by the indexing model from the issue text.