Replace direct body-parser dependency with Express built-in parser

[MMilosz]

References

none

Description

Before Express 4.16 (released in 2017), applications needed to add the separate body-parser dependency. Express now provides built-in body parsing middleware, so there is no need to add the dependency directly, especially since we rely on the default configuration.

This PR:

• removes the direct body-parser dependency
• changes server.ts to use Express's built-in parser

No functional changes intended

Instructions for Reviewers

List of changes in this PR:

• package.json: removed the direct body-parser dependency
• server.ts: uses server.use(express.json()) instead of server.use(json())

Before:

$ npm ls body-parser --depth=0
dspace-angular@11.0.0-next /tmp/dspace-angular
└── body-parser@1.20.5

After:

$ npm ls body-parser --depth=0
dspace-angular@11.0.0-next /tmp/dspace-angular
└── (empty)

(Note that --depth=0 checks direct dependencies only. body-parser will still appear as a transitive dependency of other packages e.g. Express, Karma)

To review:

• Verify that the frontend builds and starts successfully.
• Verify that frontend<>API communication works as before.

Checklist

• My PR is created against the main branch of code (unless it is a backport or is fixing an issue specific to an older branch).
• My PR is small in size (e.g. less than 1,000 lines of code, not including comments & specs/tests), or I have provided reasons as to why that's not possible.
• My PR passes ESLint validation using npm run lint
• My PR doesn't introduce circular dependencies (verified via npm run check-circ-deps)
• My PR includes TypeDoc comments for all new (or modified) public methods and classes. It also includes TypeDoc for large or complex private methods.
• My PR passes all specs/tests and includes new/updated specs or tests based on the Code Testing Guide.
• My PR aligns with Accessibility guidelines if it makes changes to the user interface.
• My PR uses i18n (internationalization) keys instead of hardcoded English text, to allow for translations.
• My PR includes details on how to test it. I've provided clear instructions to reviewers on how to successfully test this fix or feature.
• If my PR includes new libraries/dependencies (in package.json), I've made sure their licenses align with the DSpace BSD License based on the Licensing of Contributions documentation.
• If my PR includes new features or configurations, I've provided basic technical documentation in the PR itself.
• If my PR fixes an issue ticket, I've linked them together.