Fix only record owners can access workflow status API

[tylerjmchugh]

/{metadataUuid}/status/workflow/last API

Currently, only the record owner can call the workflow status /{metadataUuid}/status/workflow/last API for a given record. This means that if user1 creates a record and grants edit privileges to groupA, editors in groupA will not be able to check the workflow status, even though they have edit access.

This behavior is inconsistent with the UI logic and does not consider the metadata/history/accesslevel setting.

This PR aims to fix this issue by changing the API permission check to be consistent with the metadata/history/accesslevel setting. After this fix when metadata/history/accesslevel is set to:

• Registered User: User must be a registered user or higher and have view permissions to see the workflow status
• Editor: User must be an editor or higher and have edit permissions on the record to see the workflow status
• Administrator: User must be an administrator to see the workflow status

/status/search API

The /status/search API was updated to do some checks when the metadata/history/accesslevel was implemented in #7450 but the logic doesn't actually check that the user has the required profile.

The profile is only used to determine if the user needs view privileges (RegisteredUser) or edit privileges (Editor or Administrator). This means that with metadata/history/accesslevel set to administrator an editor can see the history as long as they have edit privileges on the record.

As I implemented updated logic to actually check the profile in the /{metadataUuid}/status/workflow/last API I have brought similar logic into the /status/search API.

Messages

Messages have been replaced with message keys to support multilingual translations, and the original message about record ownership has been removed since it is no longer used.

Checklist

• I have read the contribution guidelines
• Pull request provided for main branch, backports managed with label
• Good housekeeping of code, cleaning up comments, tests, and documentation
• Clean commit history broken into understandable chucks, avoiding big commits with hundreds of files, cautious of reformatting and whitespace changes
• Clean commit messages, longer verbose messages are encouraged
• API Changes are identified in commit messages
• Testing provided for features or enhancements using automatic tests
• User documentation provided for new features or enhancements in manual
• Build documentation provided for development instructions in README.md files
• Library management using pom.xml dependency management. Update build documentation with intended library use and library tutorials or documentation