Delay DSClient start to fix 'Disappearing Chooser problem

[chauser]

This change is motivated by observing that when SmartDashboard learns the robot address from the DriverStation prior to processing the save.xml file, sendable choosers listed in the save.xml file do not appear. It seems likely that the same issue underlies the misbehaving buttons identified in #81.

Disabling the NetworkTables DriverStation client "fixes" the problem of StringChoosers not appearing on SmartDashboard in the following specific circumstances: the String Chooser is listed in the SmartDashboard save.xml file; and the DriverStation program is running (on the same computer) and connected to the robot when the SmartDashboard program is started. The problem occurs because in this situation SmartDashboard processes the incoming NetworkTable entries before processing the save.xml file. Why this leads to the chooser not appearing is still unknown to me -- fixing that would maybe be a better approach but I have not been able to figure out why this specifically affects Choosers (and probably buttons as in #81).

In this PR, the DSClient is stopped initially and then restarted after the save.xml file is processed. A half-second sleep is inserted after starting the DSClient before setting the team number/ip from the preferences file -- this gives the DSClient time to learn the robot address before attempting to connect using the info from the preferences. Nothing bad happens if it attempts to connect using that info -- it may work or it may suffer a connection timeout if the preferences info is wrong in which case the info from the DSClient gives success on the next connection attempt.

This all feels like standing on a floor made of jello -- remember that SmartDashboard is pinned to WPILib as of 2021 in addition to having no maintainers who actually know details of how it is designed to work. Still, I think this is an improvement in the team experience versus having widgets not show up. (See #173 for my effort at moving SmartDashboard to WPILib 2023.4.3 and NT4.)

[PeterJohnson]

Can the DS client be enabled after the save file has been loaded? There is a real reason to have that enabled, as it makes connecting more robust in a field environment. Alternatively, could everything in the static block be moved to a function and called after the save file is loaded?

[chauser]

@PeterJohnson I think my latest update and your comment crossed in the mail -- it should now work as you suggest.

[chauser]

@PeterJohnson Well maybe I'm getting close to the root cause of this problem (instead of pasting it over with tweaks to startup order). The SD code calls Robot.getTable repeatedly for each table. I think that the problem is that Robot.getTable calls NetworkTable.getTable each time, and that in turn creates a new NetworkTable each time with a new entries hashmap. (Remember this is NetworkTables as of 2021.) I'm thinking that if Robot.java maintains a hashmap of tables (keyed by tableName) it can return the same one every time. I suspect that there are other misbehaviors in SD that are related to this as well -- things not showing up on LiveWindow, multiple widgets that reference the same key etc. I've seen such things happening but have not precisely characterized them.
Questions: do you know if other apps faced this problem with WPILib 2021 and if there might be code in one of them that solves the problem? Would you suggest a different approach than what I outlined above?

(I put this PR back in Draft status, hoping it can be supplanted by one fixing the root cause.)

[chauser]

Multiple tables is not the cause of the problem (or at least not the only cause). After fixing that the behavior is the same. Still looking.

[chauser]

After figuring out how to use the DSClient so it didn't cause problems, the changes here were put back into PR #185 so this PR is no longer needed.