feat(ingestor): validation exception handler

[emileten]

• add handler for ingestor API invalid request exceptions, so that more informative errors are returned to users of the API
• modify ingestor tests accordingly
• make item_assets optional in the Collection schemas.

[alukach]

I am not familiar with why this change is desired. Can you provide more of the backstory?

[sharkinsspatial]

With respect to the exception response formatting, I'd tend to agree with @alukach here. In this case, users are not directly parsing the POST response body so I think maintaining a focus on single line returns with a status code that is easily parsable from the logs is the best approach.

With the respect to the item_assets, I'd recommend the following

• Let's make a separate PR which implements a feature flag configuration to make this validation configurable.
• When we complete Break out STAC Ingestor codebase into separate repo #4 we had discussed the option of making validation code pluggable so that any consumer application could specify their own validation module that would be injected into the cdk-pgstac construct when the ingestor handler is created. This could be a good first use case for that functionality.

As an aside, can we try to limit the scope of PR's to a functional change. As an example, the title of this PR is feat(ingestor): validation exception handler while the item_assets change is related (as I assume this was the validation error you were hitting and wanted better messages about 😄 ) it makes a bit harder to review and track when we mix functional changes in a single PR.

[emileten]

As an aside, can we try to limit the scope of PR's to a functional change. As an example, the title of this PR is feat(ingestor): validation exception handler while the item_assets change is related (as I assume this was the validation error you were hitting and wanted better messages about 😄 ) it makes a bit harder to review and track when we mix functional changes in a single PR.

Yes I agree, but I was hesitant between doing what you say -- split commits based on functionality -- or keep them together to avoid having too many automatic releases happening.

[sharkinsspatial]

@emileten I hear your pain on the automated releases. Thus far I feel like semantic-release-bot has been a bit to much magic and makes the release process too opaque. If @alukach agrees I think we should consider removing it and moving to a manual tag driven release model.

[alukach]

I agree that better-scoped PRs are a good thing. Regarding the future of Semantic Release bot, let's work through that on #37