Ido*sqlConnection#InternalDeactivateObject(): mark object inactive also in memory

[Al2Klimov]

Previously:
1. You delete an object from a config file
2. You reload Icinga
3. Icinga fetches all objects and whether they're active from the IDO
4. Icinga recognizes that the just deleted object doesn't exist anymore
5. Icinga marks it as inactive in the IDO, but not in memory
6. You re-create the just deleted object via API
7. Icinga still thinks it's active and doesn't activate it - it's invisible

fixes #8584

[Al2Klimov]

Before

After

[julianbrost]

I've found how to reliably trigger this issue using only using the API (tested against 2.12.3). The key is that the host has to exist in the database when Icinga starts (or to be more precise: when Icinga (re)connects to the database).

1. Create a host: curl -skSu root:icinga -H 'Accept: application/json' -X PUT https://127.0.0.1:5665/v1/objects/hosts/host-8584 -d '{"attrs":{"check_command":"dummy"}}'
2. Restart Icinga 2: curl -skSu root:icinga -H 'Accept: application/json' -X POST https://localhost:5665/v1/actions/restart-process
3. Delete the host: curl -skSu root:icinga -H 'Accept: application/json' -X DELETE https://localhost:5665/v1/objects/hosts/host-8584
4. Recreate the same host: curl -skSu root:icinga -H 'Accept: application/json' -X PUT https://127.0.0.1:5665/v1/objects/hosts/host-8584 -d '{"attrs":{"check_command":"dummy"}}'

Other insights when investigating this: DbConnection::SetObjectActive() is only ever called in Ido{My,Pg}sqlConnection::Reconnect() (before this PR), so DbConnection::GetObjectActive() always reflects the state when establishing the DB connection, not considering any runtime updates.

This only results in a problem when activating objects, as there it is checked whether the object is considered to be active, while when deactivating an objects, this is already ignored:

icinga2/lib/db_ido/dbconnection.cpp

Lines 447 to 475 in aa4f530

	bool dbActive = GetObjectActive(dbobj);
	bool active = object->IsActive();
	if (active) {
	if (!dbActive)
	ActivateObject(dbobj);
	Dictionary::Ptr configFields = dbobj->GetConfigFields();
	String configHash = dbobj->CalculateConfigHash(configFields);
	ASSERT(configHash.GetLength() <= 64);
	configFields->Set("config_hash", configHash);
	String cachedHash = GetConfigHash(dbobj);
	if (cachedHash != configHash) {
	dbobj->SendConfigUpdateHeavy(configFields);
	dbobj->SendStatusUpdate();
	} else {
	dbobj->SendConfigUpdateLight();
	}
	} else if (!active) {
	/* This may happen on reload/restart actions too
	* and is blocked above already.
	*
	* Deactivate the deleted object no matter
	* which state it had in the database.
	*/
	DeactivateObject(dbobj);
	}

So this PR fixes the issue but I think it can still be improved, either:

1. fix the in-memory set of active objects to always reflect the state in the database (with the current PR, the set contains all that were active when connecting to the DB minus those that were deactivated after that, even though they could have been reactivated)
2. get rid of this in-memory set altogether, it is only used to optimize away a single UPDATE icinga_objects SET is_active = 1 WHERE object_id = ... where this optimization isn't even done when deactivating objects (i.e. the same query with SET is_active = 0)

[julianbrost]

see #8626 (comment)

[Al2Klimov]

I'd leave this (change to an old-gen backend) as simple as possible as long as actually fixes the issue and doesn’t break anything.

[julianbrost]

Would adding SetObjectActive(dbobj, true); in the appropriate places be really so much more complex that you want to avoid it? I think this should be fairly easy and then we have a consistent state here instead of some still half-broken set.

(Upon closer consideration, option 2 would probably need a bit more evaluation whether running a noop update query on each object on startup would hurt performance too much.)

[julianbrost]

The current state was deemed good enough for IDO.