Debian needrestart always wants the graylog-datanode.service to restart

Same Problem descriped in https://github.com/Graylog2/graylog2-server/issues/20949 now occurs for the graylog-datanode. Needrestart always wants to restart the graylog-datanode.service, even when there are no changes to the binaries.

## Expected Behavior
Needrestart should only restart the graylog-datanode.service if there are actual changes in the binaries.

## Current Behavior
Needrestart always wants to restart the graylog-datanode.service, even when there are no changes to the binaries.

## Possible Solution
Same as in https://github.com/Graylog2/fpm-recipes/commit/c7837b3d9404b836b601b4bcbb456291f50cca41 for the graylog-datanode.service

## Steps to Reproduce (for bugs)
1. Install needrestart
2. Run needrestart
3. You will see that needrestart wants to restart the graylog-datanode.service

## Context
Problem is the line `uses deleted /var/lib/graylog-datanode/opensearch/config/native_libs/libzstd-jni-1.5.7-313825061921250902695.so`:

```
root@monitoring [/etc/needrestart]:needrestart -v
[main] eval /etc/needrestart/needrestart.conf
[main] eval /etc/needrestart/conf.d/500-graylog.conf
[main] needrestart v3.11
[main] running in root mode
[Core] Using UI 'NeedRestart::UI::stdio'...
[main] systemd detected
[main] vm detected
[main] #1177388 is /usr/share/graylog-datanode/jvm/bin/java
[main] #1177388 uses deleted /var/lib/graylog-datanode/opensearch/config/native_libs/libzstd-jni-1.5.7-313825061921250902695.so
[main] #1177388 is not a child
[Core] #1177785 is a NeedRestart::Interp::Java
[Core] #1178031 is a NeedRestart::Interp::Java
[main] #1177388 exe => /usr/share/graylog-datanode/jvm/bin/java
[Core] #1177388 is a NeedRestart::Interp::Java
[Core] #1177388 source is UNKNOWN
[main] #1177388 is graylog-datanode.service
...
```

## Your Environment

* Graylog Version: 6.3.4+73b7fca
* Java Version:
* OpenSearch Version:
* MongoDB Version: v8.0.15
* Operating System: Debian
* Browser version:

## Checklist
[] This issue fix need to be backported.
[] Does this issue have **security** implications?