feat: add tesseract serve --skip-health-check argument

[dionhaefner]

Relevant issue or PR

n/a

Description of changes

Sometimes Tesseracts are expected to take a long time to start up, e.g. when JIT compiling or loading model weights. In this case, health checks can time out even though nothing's wrong with the Tesseract per se. This introduces a skip_health_check arg to serve providing users with a workaround.

Testing done

CI

[codecov]

Codecov Report

❌ Patch coverage is 48.14815% with 14 lines in your changes missing coverage. Please review.
✅ Project coverage is 77.08%. Comparing base (a092114) to head (1df316d).

Files with missing lines	Patch %	Lines
tesseract_core/sdk/engine.py	48.14%	13 Missing and 1 partial ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #596      +/-   ##
==========================================
+ Coverage   77.07%   77.08%   +0.01%     
==========================================
  Files          32       32              
  Lines        4488     4491       +3     
  Branches      738      739       +1     
==========================================
+ Hits         3459     3462       +3     
- Misses        726      727       +1     
+ Partials      303      302       -1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[PasteurBot]

Benchmark Results

Benchmarks use a no-op Tesseract to measure pure framework overhead.

🚀 0 faster, ⚠️ 2 slower, ✅ 34 unchanged

Notable changes

Benchmark	Baseline	Current	Change	Status
decoding/binref_100,000	0.255ms	0.283ms	+10.8%	⚠️ slower
encoding/base64_100,000	0.182ms	0.209ms	+14.8%	⚠️ slower

Full results

Benchmark	Baseline	Current	Change	Status
api/apply_1,000	0.396ms	0.397ms	+0.1%	✅
api/apply_100,000	0.396ms	0.398ms	+0.6%	✅
api/apply_10,000,000	0.392ms	0.404ms	+2.9%	✅
cli/apply_1,000	1531.943ms	1554.195ms	+1.5%	✅
cli/apply_100,000	1521.655ms	1546.772ms	+1.7%	✅
cli/apply_10,000,000	1618.651ms	1613.075ms	-0.3%	✅
decoding/base64_1,000	0.028ms	0.028ms	-1.6%	✅
decoding/base64_100,000	0.785ms	0.813ms	+3.5%	✅
decoding/base64_10,000,000	114.327ms	113.038ms	-1.1%	✅
decoding/binref_1,000	0.168ms	0.175ms	+4.4%	✅
decoding/binref_100,000	0.255ms	0.283ms	+10.8%	⚠️ slower
decoding/binref_10,000,000	20.640ms	20.519ms	-0.6%	✅
decoding/json_1,000	0.090ms	0.090ms	-0.2%	✅
decoding/json_100,000	8.372ms	8.373ms	+0.0%	✅
decoding/json_10,000,000	1049.764ms	1067.368ms	+1.7%	✅
encoding/base64_1,000	0.035ms	0.034ms	-1.7%	✅
encoding/base64_100,000	0.182ms	0.209ms	+14.8%	⚠️ slower
encoding/base64_10,000,000	48.794ms	50.024ms	+2.5%	✅
encoding/binref_1,000	0.233ms	0.236ms	+1.5%	✅
encoding/binref_100,000	0.388ms	0.408ms	+5.2%	✅
encoding/binref_10,000,000	23.533ms	24.283ms	+3.2%	✅
encoding/json_1,000	0.119ms	0.120ms	+0.7%	✅
encoding/json_100,000	10.738ms	10.845ms	+1.0%	✅
encoding/json_10,000,000	1225.425ms	1266.191ms	+3.3%	✅
http/apply_1,000	3.045ms	2.813ms	-7.6%	✅
http/apply_100,000	8.755ms	8.896ms	+1.6%	✅
http/apply_10,000,000	774.901ms	785.496ms	+1.4%	✅
roundtrip/base64_1,000	0.071ms	0.070ms	-0.9%	✅
roundtrip/base64_100,000	1.158ms	1.158ms	-0.0%	✅
roundtrip/base64_10,000,000	169.767ms	159.630ms	-6.0%	✅
roundtrip/binref_1,000	0.415ms	0.420ms	+1.3%	✅
roundtrip/binref_100,000	0.643ms	0.655ms	+2.0%	✅
roundtrip/binref_10,000,000	47.458ms	43.068ms	-9.2%	✅
roundtrip/json_1,000	0.217ms	0.220ms	+1.3%	✅
roundtrip/json_100,000	18.424ms	18.189ms	-1.3%	✅
roundtrip/json_10,000,000	2290.607ms	2280.627ms	-0.4%	✅

• Runner: Linux 6.17.0-1013-azure x86_64

[jpbrodrick89]

LGTM, for these long startup Tesseracts do we have any recommendation users for the best way to probe when the Tesseract is ready? Do they just need to manually run health/another endpoint call until they don't get a connection error? Is it easy to setup a feature such that all Tesseracts write to their logs when ready or is that something the Tesseract create needs to manually code in?