find and remove long user loop times at the start of auto

[gcschmit]

I noticed that we have two very long loop (100+ ms) times at the start of auto. That can negatively impact performance. This would be a good opportunity to try VisualVM to profile our code. There is guide on wpilib docs.

We may need to potentially adjust roboRIO memory settings and disable its web server.

[gcschmit]

Based on the VisualVM analysis, refreshing configs in setBrakeMode is very expensive. While it is convenient to have the drive motors in coast mode when disabled, a lag at the start of auto isn't acceptable. We will need to think of an alternative approach.

For some reason, invoking getMotorVoltage in updateSwerveModuleInputs in the DrivetrainIOCTRE class is very expensive. I'm not sure why this method is expensive and not similar ones like getStatorCurrent. It may be because of the order of the method invocations and the other values are cached. Perhaps we should create signal objects for everything and add them to the refreshAll invocation.

Another insight is that repeatedly invoking the setControl method on a motor object is also expensive. We need to ensure that we don't repeatedly invoke this method with the same values like we currently do in the intake. Instead, calls like this should be done on state transitions.

Here's the VisualVM file for a few seconds at the start of auto.
snapshot2.nps.zip