perf(robot-server): Flatten FastAPI routers

[SyntaxColoring]

Overview

The Pydantic v1->v2 update makes server startup much slower. It turns out that a surprisingly large portion of that problem is due to inefficiencies in FastAPI's .include_router() method. This works around that.

Closes EXEC-1067.

Performance testing

	Pydantic v1*	Pydantic v2 before this PR	Pydantic v2 with this PR
import robot_server.app on my laptop	~2.3s (flame graph)	~6.0s (flame graph)	~3.5s (flame graph)
import robot_server.app on a robot (estimated)		3-ish minutes (estimated)	2-ish minutes (estimated)
robot-server's entire lint+test CI workflow	~13 min	~21 min	~15 min

*Note that the comparison against Pydantic v1 is a bit apples-to-oranges, because Pydantic v2 does more things during import time so it can be faster after import time.

Raw flame graph files here.

Correctness testing

• Make sure the integration tests keep keep passing.
• Skim OpenAPI docs and make sure it doesn't look like anything has changed.

I could also add more focused unit tests for this if we think it's worth the time.

Changelog

Our constraints are basically:

• On one hand, we want to call FastAPI's .include_router() as little as possible, for performance.
• On the other, we do not want to reorganize our whole codebase around this. We want to keep organizing our routers as a tree, and we probably want everything to remain basically API-compatible with normal FastAPI. For instance, some future version of FastAPI might fix the underlying problem, so it would be good if we could easily undo all of this.

Therefore:

• In server_utils, build a drop-in replacement for FastAPI's APIRouter. It is basically a subset of APIRouter's interface and functionality. There is some "cleverness" here to avoid having to duplicate the giant method signatures of .get(), .post(), etc.
• In robot_server, switch as much as we can over to the drop-in. This is basically just a find+replace job, but there are a couple of small gotchas.

Review requests

• Is there a cleaner alternative to my typing shenanigans? Should we just duplicate the method signatures from FastAPI?
• Does the code explain itself well enough? Any naming or documentation feedback?
• Is the performance improvement worth the complexity and weirdness? I've spent probably too long on this, but I wouldn't take it personally if we wanted to drop it and just eat the performance hit.

Risk assessment

Medium.

If something goes wrong here, I'd bet it would be in the part where we merge kwargs from different levels of the router tree. We want to match FastAPI behavior there, which seems like it can be pretty nuanced. Also, it is just some ugly dict manipulation.

[TamarZanzouri]

I think this approach is clear. The only rename I would change is the _SomethingCallableLike to _CallableLike but no biggy. Thank you for fixing this!