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 76.84%. Comparing base (7170c9f) to head (2123b57).

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.11%   76.84%   -0.28%     
==========================================
  Files          32       32              
  Lines        4492     4495       +3     
  Branches      738      739       +1     
==========================================
- Hits         3464     3454      -10     
- Misses        725      738      +13     
  Partials      303      303              

☔ 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, ⚠️ 0 slower, ✅ 36 unchanged

✅ No significant performance changes detected.

Full results

Benchmark	Baseline	Current	Change	Status
api/apply_1,000	0.586ms	0.587ms	+0.1%	✅
api/apply_100,000	0.589ms	0.591ms	+0.4%	✅
api/apply_10,000,000	0.589ms	0.588ms	-0.2%	✅
cli/apply_1,000	1661.488ms	1667.249ms	+0.3%	✅
cli/apply_100,000	1669.496ms	1676.648ms	+0.4%	✅
cli/apply_10,000,000	1721.366ms	1718.115ms	-0.2%	✅
decoding/base64_1,000	0.037ms	0.036ms	-1.0%	✅
decoding/base64_100,000	0.635ms	0.657ms	+3.5%	✅
decoding/base64_10,000,000	67.863ms	68.490ms	+0.9%	✅
decoding/binref_1,000	0.200ms	0.204ms	+2.3%	✅
decoding/binref_100,000	0.241ms	0.242ms	+0.5%	✅
decoding/binref_10,000,000	10.694ms	10.853ms	+1.5%	✅
decoding/json_1,000	0.107ms	0.105ms	-1.4%	✅
decoding/json_100,000	8.740ms	8.731ms	-0.1%	✅
decoding/json_10,000,000	1059.759ms	1065.134ms	+0.5%	✅
encoding/base64_1,000	0.041ms	0.039ms	-2.8%	✅
encoding/base64_100,000	0.145ms	0.147ms	+1.2%	✅
encoding/base64_10,000,000	25.733ms	25.869ms	+0.5%	✅
encoding/binref_1,000	0.311ms	0.312ms	+0.3%	✅
encoding/binref_100,000	0.484ms	0.491ms	+1.5%	✅
encoding/binref_10,000,000	18.770ms	19.049ms	+1.5%	✅
encoding/json_1,000	0.152ms	0.149ms	-2.0%	✅
encoding/json_100,000	13.043ms	13.079ms	+0.3%	✅
encoding/json_10,000,000	1413.668ms	1398.431ms	-1.1%	✅
http/apply_1,000	3.167ms	3.139ms	-0.9%	✅
http/apply_100,000	8.963ms	9.048ms	+0.9%	✅
http/apply_10,000,000	759.589ms	759.659ms	+0.0%	✅
roundtrip/base64_1,000	0.086ms	0.087ms	+1.5%	✅
roundtrip/base64_100,000	0.733ms	0.738ms	+0.6%	✅
roundtrip/base64_10,000,000	94.547ms	95.277ms	+0.8%	✅
roundtrip/binref_1,000	0.529ms	0.540ms	+2.1%	✅
roundtrip/binref_100,000	0.736ms	0.739ms	+0.5%	✅
roundtrip/binref_10,000,000	29.912ms	30.131ms	+0.7%	✅
roundtrip/json_1,000	0.267ms	0.270ms	+1.0%	✅
roundtrip/json_100,000	19.548ms	19.838ms	+1.5%	✅
roundtrip/json_10,000,000	2462.971ms	2474.793ms	+0.5%	✅

• 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?