Instance deregistration endpoint

[arbulu89]

Description

Add application/database instance deregistration (deletion) endpoints.

It adds the /api/v1/sap_systems/#{sap_system_id}/hosts/#{host_id}/instances/#{instance_number} (and the equivalent database endpoint). We need the 3 primary keys to know which instance to deregister.
Maybe there is some better way using params or similar, instead of having all the fields required in the field.

Besides that, it includes a basic domain logic to forbid the deletion of instances that are not absent.

The usage of the absent field logic in the endpoint is in the use cases code. This is because I didn't want to add this logic in the domain logic, as this would impact the whole deregistration processes (when the instances are deregistered on a host deregistration request for example). This way, this condition is only used when it these specific delete endpoints are used.

PD: The PR adds the fields and the migrations in the read models the way I would expect to be done in the side effects part

@nelsonkopliku @dottorblaster just putting you here if you want to have a look simply on the created routes. Maybe you have some suggestion in that matter

[nelsonkopliku]

I al ok with the added routes.
Probably you already considered adding a /deregister suffix or similar and ditched it. I would not be against it.

I cannot but wonder about the relation of this PR with jamie's #1731 and the absent-deregister relation.
Are they two different things? As in marking something absent first and then eventually deregistering it? Am I getting it right?

Finally: the logic about being able to deregister or not an absent instance really looks like domain logic of the SAP system aggregate. I have not been in the loop, so I might be missing something.

Besides this just some typo fix suggestions.

[arbulu89]

I cannot but wonder about the relation of this PR with jamie's #1731 and the absent-deregister relation. Are they two different things? As in marking something absent first and then eventually deregistering it? Am I getting it right?

Yes, they are totally related. This PR enables the user interaction to delete/deregister the instances from the web clicking a button, once they were marked as absent

Finally: the logic about being able to deregister or not an absent instance really looks like domain logic of the SAP system aggregate. I have not been in the loop, so I might be missing something.

I thought the same initially, but it totally affects the already existing deregistration logic. If we enforce this rule on the domain, we would need to do major changes in other parts. We would need to set all the instances belonging a host to absent if the host is deregisterable, which is not trivial at all.

I think all of this will have a follow up epic, where we need to start thinking of the state of the registered resources in hosts which are not reporting

[CDimonaco]

Good job, lgtm!

[CDimonaco]

I thought the same initially, but it totally affects the already existing deregistration logic. If we enforce this rule on the domain, we would need to do major changes in other parts. We would need to set all the instances belonging a host to absent if the host is deregisterable, which is not trivial at all.

Completely agree on that, for the moment we should keep that logic inside the usecase, but we can have a tech debt later to address this logic in the domain

[nelsonkopliku]

@arbulu89 @CDimonaco ok I see the complexity of putting that logic where it belongs. So I ma fine with this transition.
Let's maybe just keep track of it.

[dottorblaster]

Thanks for paging me but I think you did a wonderful job 💪