adds bug fix for db errors

[tonytheleg]

PR Template:

Describe your changes

• updates the error checking logic for create/update/delete to ensure any query-related errors are captured
• updates compose files to ensure dependency on migration call completing
• minor update to example files to include workspace_id's
• update to reporter-relationship json file to use local_resource_id to allow for deleting

Reason:
While testing some of the base API calls in the readme, all Create calls would result in
{"code":500, "reason":"", "message":"resource already exists", "metadata":{}} even on a fresh run with new db

After debugging, the error was due to bad start up process with docker compose:
no such table: local_inventory_to_resources

The proposed changes will ensure we capture any errors and return them unless the record is not found in which the proper actions should occur.

Also updated the depends_on values to include the invmigrate pod on inventory-api to ensure the DB is properly set.

Validation:

# create
$ curl -H "Content-Type: application/json" -d @data/host.json localhost:8081/api/inventory/v1beta1/resources/rhel-hosts
{}

# create again properly says resource found
$ curl -H "Content-Type: application/json" -d @data/host.json localhost:8081/api/inventory/v1beta1/resources/rhel-hosts
{"code":500,"reason":"","message":"resource already exists","metadata":{}}[anatale@fedora-csb inventory-api]

# put allows update on existing resource
$ curl -X PUT -H "Content-Type: application/json" -d @data/host.json localhost:8081/api/inventory/v1beta1/resources/rhel-hosts
{}

# delete
$ curl -X DELETE -H "Content-Type: application/json" -d @data/relationship_reporter_data.json localhost:8081/api/inventory/v1beta1/resources/rhel-hosts 
{}

# delete properly errors when not found
$ curl -X DELETE -H "Content-Type: application/json" -d @data/relationship_reporter_data.json localhost:8081/api/inventory/v1beta1/resources/rhel-hosts 
{"code":500,"reason":"","message":"resource not found","metadata":{}}

Ticket reference (if applicable)

Fixes #

Checklist

• Are the agreed upon acceptance criteria fulfilled?

• Was the 4-eye-principle applied? (async PR review, pairing, ensembling)

• Do your changes have passing automated tests and sufficient observability?

• Are the work steps you introduced repeatable by others, either through automation or documentation?

  • If automation is possible but not done due to other constraints, a ticket to the tech debt sprint is added
  • An SOP (Standard Operating Procedure) was created

• The Changes were automatically built, tested, and - if needed, behind a feature flag - deployed to our production environment. (Please check this when the new deployment is done and you could verify it.)

• Are the agreed upon coding/architectural practices applied?

• Are security needs fullfilled? (e.g. no internal URL)

• Is the corresponding Ticket in the right state? (should be on "review" now, put to done when this change made it to production)

• For changes to the public API / code dependencies: Was the whole team (or a sufficient amount of ppl) able to review?

[josejulio]

lgtm