[202311] Fix pstore service not running

[DavidZagury]

Why I did it

The pstore service is not able to start, even if there are backtrace for kernel panics/oops in the UEFI.
This carry a risk of filling up the UEFI storage space.
This fixes the issue - #18895

Work item tracking

• Microsoft ADO (number only):

How I did it

Systemd on newer version has fixed this issue by adding a dependency on the kernel module to ensure we only scan for
pstate after we can actually see pstate.
Took this fix to our system.

How to verify it

Simulate a kernel crash, and make sure that when system is live again, the backtrace are located on /var/lib/systemd/pstore/ and not /sys/fs/pstore/

Which release branch to backport (provide reason below if selected)

• 201811
• 201911
• 202006
• 202012
• 202106
• 202111
• 202205
• 202211
• 202305

Tested branch (Please provide the tested image version)

Description for the changelog

Link to config_db schema for YANG module changes

A picture of a cute animal (not mandatory but encouraged)

[DavidZagury]

/azpw run Azure.sonic-buildimage

[mssonicbld]

/AzurePipelines run Azure.sonic-buildimage

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[dprital]

@saiarcot895 , Can you please approve this PR ?

[dprital]

@saiarcot895 , Can you please review and approve ?

[dprital]

@yxieca , Can you please merge ?

[yxieca]

@DavidZagury @dprital can you confirm that this change is only needed for 202311? master branch has fix by default already? I think your PR comments implies this but please confirm.

[DavidZagury]

@yxieca, yes, this PR fixes a bug in Systemd version 247.3 (systemd/systemd#18540)

This bug was fixed on newer versions of Systemd, Debian Bookworm already uses the version with the fix.
Systemd version 247.3 is used on Debian Bullseye, so this PR brings the same correct behavior to 202311.

It can be used in other branches based on Bullseye, but since master (and 202405) has the fix already it is not needed for them.