tests: defer global imports and remove pytest parametrize decorators

[PhantomInTheWire]

relevant issue: #1184

Branch	Collection Time (Linux CI)	Total Test Time
master	0.7-1 sec	~25 – 30 sec
PR	0.3-0.4 sec	~25 - 30 sec

root cause:

Most of the overhead came from heavy import statements, especially files like opendbc/car/values.py, opendbc/car/interfaces.py, opendbc/car/car_helpers.py etc. Importing even one of these would trigger a chain of imports, pulling in most of the others. deferring imports from global scope to local scope fixed it.(mostly)

I had to remove parametrize in some places because it required global imports, and replaced it with for loops and subtests. In the case of opendbc/car/tests/test_car_interfaces.py, this caused a slowdown since that file has many tests that previously ran in parallel but were now running on a single worker. To fix this, I used a combination of fixtures and batched parametrize to get parallelism back.

Update: I deffered some more imports in test_mutation.py, test_ford/hyundai/toyota.

I also converted an expensive ffi call from collection time to runtime in

[sshane]

I'm only seeing a reduction of 1s to 0.7s collection time with pytest --co opendbc and inconsistent results with the total test time (baseline 25s, one run was 19s, one run was 27s)

[PhantomInTheWire]

hello @sshane I was under the impression that we needed to reduce collection time for pytest --co opendbc/car/tests since the orignal issue mentioned "pytest: slow collection for car/tests/ #1184
can/tests/ is 20x faster to collect than car/tests/." I'll push a fix for pytest --co opendbc but while I do that can you confirm if this is the right approach and this is what i'm supposed to do?

[PhantomInTheWire]

as for total test time that seems to be inconsistent on master as well for some reason(locally it takes anywhere between 28sec to 41 secs on my m3 macbook air)

[PhantomInTheWire]

Hello again @sshane @adeebshihadeh I’ve refactored some more tests to significantly decrease collection time. It’s not quite <=0.1s yet, but the current PR has already reached the ~500 line limit. It would be best if further optimizations were handled in another PR, and this one reviewed as is. (Getting collection time down further would involve touching all of the values.py files across the codebase, which would be a large refactor, so it's best if that is a seperate pr)

[PhantomInTheWire]

Hello again @sshane @adeebshihadeh just following up on this pr, did you have a chance to look at it yet? thanks(the benchmarks in pr desc have been updated btw)