Fix SR status broadcast on database instance registration

[arbulu89]

Description

Fix system replication status broadcast on database instance registration.
Basically, we need all database instances to get the value for each type (primary/secondary).

I want to test this with the whole "restoration" fix for the instances (#1673)

PD: I do agree that this got complex, so querying with a api call on this events as refactor would be a good idea.
PD2: In fact, it has "forced" me to change some domain events order to make it work without horrible "data enrichment" messages to the frontend...

How was this tested?

Everything tested in the projection. I didn't add any test on the view, as the test would be the same.

[rtorrero]

@arbulu89 looks good to me. Just for a better understanding: what made you have to change the order of the restoration event? (not questioning it, I think it's intuitively makes more sense to me this way)

[arbulu89]

@arbulu89 looks good to me. Just for a better understanding: what made you have to change the order of the restoration event? (not questioning it, I think it's intuitively makes more sense to me this way)

Already commented in our internal Slack channel, but here we go again 😆

In order to calculate the Active pill, we need to have all the database instances (specially the primary) present in the database.
During the restoration, we can have a corner case (or normal case, depending what you do...), where you deregister the database simply removing the Primary instance, and letting the Secondary there, without removing, but it is not showing up in the console, so it stays as "zombie".

When you restore the Primary instance, the Secondary was already present there, so it is sent to the Frontend together with the DatabaseRestore event, but as the primary was not there, the Active pill couldn't be calculated, so it is not set.
To calculate it we need the Primary.

Changing the order, maker the Primary instance read model being present in the database for the moment we do the query to do the calculation

I'm saying this is a corner case, because in a normal flow, you couldn't never have a Secondary there without previously having a Primary, but as it stayed as zombie...