fix: catch error within customerIntent endpoints

[JayKid]

Description

Return status code instead of throwing the whole handler

The PR basically wraps the CRUD customerIntent endpoints in a try catch and returns appropriate status codes instead of allowing the hasAccess function throwing an error to crash the handler.

Please ensure your pull request adheres to the following guidelines:

• make sure to link the related issues in this description. Or if there's no issue created, make sure you
  describe here the problem you're solving.
• when merging / squashing, make sure the fixed issue references are visible in the commits, for easy compilation of release notes

Related Issues

• LLMO-371 | Do not throw on customerIntent endpoints when access is not valid

[github-actions]

This PR will trigger a patch release when merged.

[ravverma]

@JayKid
Rather having try/catch everywhere , I would handle the error from AccessControlUtil at one place , where it is calling the hasAccess in method getSiteAndValidateLlmo and throw forbidden with message.
https://github.com/adobe/spacecat-api-service/pull/1226/files#diff-98f4e781fc94ce98289e072f10ebfb77c9028d87b18bfdf3d455fc232f8065c0R42

[ravverma]

handle it in getSiteAndValidateLlmo method itself rather everyplace

[JayKid]

@JayKid Rather having try/catch everywhere , I would handle the error from AccessControlUtil at one place , where it is calling the hasAccess in method getSiteAndValidateLlmo and throw forbidden with message. https://github.com/adobe/spacecat-api-service/pull/1226/files#diff-98f4e781fc94ce98289e072f10ebfb77c9028d87b18bfdf3d455fc232f8065c0R42

shouldn't be the responsibility of the endpoint to choose what to return to the client, instead of doing it inside of a access helper? or did I misunderstand what you mean by:

throw forbidden with message?

[ravverma]

@JayKid Rather having try/catch everywhere , I would handle the error from AccessControlUtil at one place , where it is calling the hasAccess in method getSiteAndValidateLlmo and throw forbidden with message. https://github.com/adobe/spacecat-api-service/pull/1226/files#diff-98f4e781fc94ce98289e072f10ebfb77c9028d87b18bfdf3d455fc232f8065c0R42

shouldn't be the responsibility of the endpoint to choose what to return to the client, instead of doing it inside of a access helper? or did I misunderstand what you mean by:

throw forbidden with message?

I was just saying that changes are wrapping getSiteAndValidateLlmo in try/catch for error forbidden so better hasAccess wrapped in getSiteAndValidateLlmo once only.