Catch possible ID mismatch when trying to update a view (6.3)

[janheise]

Note: This is a backport of #26715 to 6.3.

This is a manual backport (different from 7.1/.7.3) due to conflicts so needs a more thorough review
see e.g. #26729

Description

This PR fixes an oversight in #26344

which we got notified by https://github.com/Graylog2/graylog2-server/security/advisories/GHSA-w997-cmqr-xrx6

We are now also making sure that for update, the ID from the entity matches the ID from the path. The ID is not enforced by the @Valid on the view entity as it's not necessary for creation. But for an update on an existing view, it is always present and our FE always puts it in the request.

Motivation and Context

How Has This Been Tested?

manual testing, added a unit test

Screenshots (if appropriate):

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Refactoring (non-breaking change)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have requested a documentation update.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.

[luk-kaminski]

Code looks ok, initial experiments in the test environment show that one cannot update a view if there is a mismatch of IDs:

[luk-kaminski]

Confirmed Dashboards can still be updated in the UI.
Confirmed Saved Searches can still be updated in the UI.

[luk-kaminski]

When ID match, the view can be updated (the API does not prevent you to update it so that it becomes non-operational, but that is another problem):

[luk-kaminski]

LGTM, thanks!