chore(sdk): add settings and debug for service startup issues (wait_for_ports)

[raubitsj]

Description

Add new setting to control wait for port time and debug messages to find out timings of what might be going wrong.

Testing

manually

[codecov]

Codecov Report

Merging #4749 (28ebd3f) into main (361524c) will increase coverage by 0.02%.
The diff coverage is 89.13%.

❗ Current head 28ebd3f differs from pull request most recent head 173cb7b. Consider uploading reports for the commit 173cb7b to get more accurate results

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #4749      +/-   ##
==========================================
+ Coverage   83.84%   83.86%   +0.02%     
==========================================
  Files         285      286       +1     
  Lines       35995    36029      +34     
==========================================
+ Hits        30180    30216      +36     
+ Misses       5815     5813       -2     

Flag	Coverage Δ
functest	56.98% <89.13%> (+0.07%)	⬆️
unittest	74.09% <67.39%> (-0.02%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
wandb/sdk/service/_startup_debug.py	66.66% <66.66%> (ø)
wandb/sdk/service/server.py	84.82% <90.90%> (+0.66%)	⬆️
wandb/sdk/service/service.py	89.69% <95.00%> (+0.40%)	⬆️
wandb/sdk/wandb_manager.py	94.11% <100.00%> (+0.04%)	⬆️
wandb/sdk/wandb_settings.py	94.93% <100.00%> (+<0.01%)	⬆️
wandb/sdk/wandb_setup.py	88.88% <100.00%> (+0.44%)	⬆️
wandb/sdk/interface/interface_shared.py	90.78% <0.00%> (-0.71%)	⬇️
wandb/sdk/lib/mailbox.py	93.26% <0.00%> (-0.33%)	⬇️
wandb/sdk/lib/git.py	77.71% <0.00%> (ø)
... and 3 more

[davidgilbertson]

Hi @raubitsj I was just about to create an issue for "slow init/finish times" but found this PR. Does this mean the team is working to improve the performance?
Also, is a wandb.init() time of 2 seconds and a wandb.finish() time of 5.5 seconds expected? Or is there something I can do to improve this? I'm not running a local server, and this is when not even logging anything at all, so I assume these times could be brought down to a few hundred milliseconds easily enough.