Allow renaming child nodes in _ready

[RedworkDE]

• Implements Fix scene load crash related to _ready #78654 (comment)
• Re-enables previously valid code
• Probably best as 4.2 + cherry-pick

[akien-mga]

@reduz seemed to like that idea when proposed by @kleonc in #77610 (comment). CC @Sauermann

Agree with keeping this for 4.2 and possibly a cherrypick for 4.1.1 to lift the restriction, so we don't take risks now.

[reduz]

Looks good, great approach!

[kleonc]

Overall the code looks good to me. 👍 AFAICT should be good as is, but left some notes.

[kleonc]

AFAICT only the other entries need to be "shifted by one", no point to keep moving the element we're removing (the last entry in the chain is cleared right after this loop anyway).

Suggested change

	SWAP(hashes[next_pos], hashes[pos]);
	SWAP(elements[next_pos], elements[pos]);
	hashes[pos] = hashes[next_pos];
	elements[pos] = elements[next_pos];

(under the assumption that pos != next_pos; which should be the case as next_pos = fastmod((pos + 1), capacity_inv, capacity))

---

I see in HashMap::erase it's done like that too:

godot/core/templates/hash_map.h

Lines 325 to 326 in afc5fa1

	SWAP(hashes[next_pos], hashes[pos]);
	SWAP(elements[next_pos], elements[pos]);

It could be changed the same way if the element being removed would be stored just like in here before doing all the "shifting" (HashMapElement<TKey, TValue> *element = elements[pos]) and it would be used instead of elements[pos] in:

godot/core/templates/hash_map.h

Lines 341 to 349 in afc5fa1

	if (elements[pos]->prev) {
	elements[pos]->prev->next = elements[pos]->next;
	}
	if (elements[pos]->next) {
	elements[pos]->next->prev = elements[pos]->prev;
	}
	element_alloc.delete_allocation(elements[pos]);

[RedworkDE]

This is copied as-is from erase and would rather keep it simple for this PR, same for the duplicate hash computation below (also some operations can compute the hash / lookup the element 3 or 4 times, so hash map really deserves a dedicated optimization PR with measurements etc)

[kleonc]

Agree. As mentioned, these are just some notes/thoughts. 🙃

[kleonc]

This is already calculated in _lookup_pos(p_new_key, pos) so there's a room for optimizing it.

[YuriSizov]

Thanks!