Fixes random hell call-counts to Move (#63317)

Removes the parent call from mob/Login

Mothblocks pinged me with a profile of just a hellish amount of move calls
Way too many, like 200000
Started looking into it, got distracted by how expensive macros were
Turns out most of the cost of macros was in the nuke ops summon spawner

So I looked at why, only bit of it that was at all expensive was the login for the cyborgs
Tested on a local, huh that is slow yeah

Looked at the profiler, huh there's that move count again
So anyway, why is login so expensive

Spawned a few cyborgs in, dragged myself into them, nothing
Spawned myself in with sdql magic using the summon spawner, man it really is still there
I guess it has to do with move somehow, try and stick a breakpoint on it, get fucked by the debugger
I notice the hanging comes during the Login parent call

Try again, this time with good breakpoints.
We're trying to move, to (1,1,1), just like the reference says we will https://secure.byond.com/docs/ref/#/mob/proc/Login

But man, it just keeps happening, and we don't actually move
Step through the code, we've got that null loc check in atom/movable/Move

So the move to (1,1,1) isn't working

Here's the exact line from the reference
"If the mob has no location, place it near (1,1,1) if possible"
Keyword is near

Talked to lummox about this behavior, figured it was a bug

It turns out by near, they mean inside that tile's area
It'll keep trying to place you somewhere, in an attempt to effectively cover for shitty login systems, until you succeed in moving

That tile is space. There are 200,000 tiles with the same area as it
OH.

So anyway, we're not calling parent on mob/login anymore. We can do all the work it did that we care about ourselves (IE: Just the statobj set)
And this way we don't need to worry about 4 SECONDS OF OVERTIME WHENEVER SOME POOR FUCK MESSES UP SPAWN ORDER

So yeah, I'm a genius and not at all just malding at the existance of keybind macros, and hopefully another source of stutter bites the dust
Not actually sure how widespread this is, but even if it's just spawn becacons that's pretty banging

code/modules/mob/login.dm

@@ -9,7 +9,8 @@
  * * tells the world to update it's status (for player count)
  * * create mob huds for the mob if needed
  * * reset next_move to 1
- * * parent call
+ * * Set statobj to our mob
+ * * NOT the parent call. The only unique thing it does is a very obtuse move op, see the comment lower down
  * * if the client exists set the perspective to the mob loc
  * * call on_log on the loc (sigh)
  * * reload the huds for the mob
@@ -43,7 +44,19 @@
 
 	next_move = 1
 
-	..()
+	client.statobj = src
+
+	// DO NOT CALL PARENT HERE
+	// BYOND's internal implementation of login does two things
+	// 1: Set statobj to the mob being logged into (We got this covered)
+	// 2: And I quote "If the mob has no location, place it near (1,1,1) if possible"
+	// See, near is doing an agressive amount of legwork there
+	// What it actually does is takes the area that (1,1,1) is in, and loops through all those turfs
+	// If you successfully move into one, it stops
+	// Because we want Move() to mean standard movements rather then just what byond treats it as (ALL moves)
+	// We don't allow moves from nullspace -> somewhere. This means the loop has to iterate all the turfs in (1,1,1)'s area
+	// For us, (1,1,1) is a space tile. This means roughly 200,000! calls to Move()
+	// You do not want this
 
 	if(!client)
 		return FALSE