Remove redundant component tracking.

[warriorstar-orion]

⚠️ PAY ATTENTION. THIS PR TOUCHES THE COMPONENT SYSTEM. TEST MERGING IS STRONGLY SUGGESTED. ⚠️

What Does This PR Do

Fixes #19130.

This PR excludes /datum/component from the list of types when checking for duplicate datum components.

This issue manifested itself in the failure to GC of /obj/structure/spider/spiderlings, which was traced back to the failure to find a reference to the /datum/component/spawning component attached on Initialize. However, this issue has always been present; when inspecting the datum_components of any object, the values will look something like this:

As you can see, Paperwork has two components, but his datum_components also includes a list of his components.

This is because the absence of /datum/component in the list was considered an absence of each subcomponent respectively. They are added to a list because of how the component system handles 'duplicates', components of the same subtype. Depending on the component's dupe_mode, it may attempt to merge the two, clobber one with the other, or allow the presence of both added to a list in the datum_components list, with the key being the component type, and the list values being instances of the component.

What's weird is /datum/component/proc/_GetInverseTypeList, which is where the registrar gets the list of subtypes to check. It is reproduced in its entirety below:

/datum/component/proc/_GetInverseTypeList(our_type = type)
	//we can do this one simple trick
	var/current_type = parent_type
	. = list(our_type, current_type)
	//and since most components are root level + 1, this won't even have to run
	while (current_type != /datum/component)
		current_type = type2parent(current_type)
		. += current_type

I don't really understand the comment; it seems to understand that it would in fact be included /datum/component in the results (1: "most components are root level + 1", 2: it adds the parent_type to the list first thing). So it sounds as if the behavior is intended. But I'm confident that the existing behavior is broken. Even more confusing, I can't find any components that are second level children of /datum/component, so I don't know why it's looking at all. But if it is indeed the case that a /datum/component/foo/bar/baz exists, we can't just remove the assignation of the parent type to the list here. We have to check after the fact.

I also don't know why /datum/component's dupe_mode of COMPONENT_DUPE_HIGHLANDER (i think it just lets the latest version win) doesn't cause any issues here, instead obediently adding each subcomponent in turn to what it believes is a list of duplicate components.

This also removes an unnecessary list allocation to any object with a component. This may provide a negligible performance boost.

Why It's Good For The Game

GC failures are bad

Images of changes

Testing

Spawned 100 spiderlings, waited for them to grow up, inspected del log.

Before:

After:

Changelog

🆑
fix: Fixed an issue which prevented spiderlings from GC'ing
/:cl:

[warriorstar-orion]

Wait, no, I don't trust this. There's actually code that relies explicitly on that nested sublist.