op-conductor: add JSON-based rollup-boost healthcheck with -next suffix

[teddyknox]

Adds a new JSON-based rollup-boost healthcheck alongside the existing HTTP status code-based implementation.

Standard healthcheck (--rollup-boost.enabled):

• Interprets HTTP status codes (200=healthy, 206=partial, 503=unhealthy)
• URL derived from execution.rpc with /healthz appended automatically

Next healthcheck (--rollup-boost.next-enabled):

• Parses JSON response body for health status
• Requires explicit full URL via --rollup-boost.next-healthcheck-url

The two modes are mutually exclusive. Both use the same --rollup-boost.healthcheck-timeout setting.

CLI/ENV Changes

Existing (unchanged)	New
--rollup-boost.enabled	--rollup-boost.next-enabled
--rollup-boost.healthcheck-timeout (shared)	--rollup-boost.next-healthcheck-url
OP_CONDUCTOR_ROLLUP_BOOST_ENABLED	OP_CONDUCTOR_ROLLUP_BOOST_NEXT_ENABLED
OP_CONDUCTOR_ROLLUP_BOOST_HEALTHCHECK_TIMEOUT (shared)	OP_CONDUCTOR_ROLLUP_BOOST_NEXT_HEALTHCHECK_URL

Breaking Changes

None. Existing users of --rollup-boost.enabled are unaffected.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 80.21%. Comparing base (c2ffd4f) to head (a82c82e).
⚠️ Report is 20 commits behind head on develop.

Additional details and impacted files

@@             Coverage Diff             @@
##           develop   #18453      +/-   ##
===========================================
+ Coverage    75.31%   80.21%   +4.90%     
===========================================
  Files          187      132      -55     
  Lines        11199     7168    -4031     
===========================================
- Hits          8434     5750    -2684     
+ Misses        2621     1418    -1203     
+ Partials       144        0     -144     

Flag	Coverage Δ
cannon-go-tests-64	?
contracts-bedrock-tests	80.21% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.
see 55 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[jelias2]

So this is only for health checking a kona rollup-boost, not for healthchecking kona as pure CL?

If its pure CL it should fit into the existing heathchecks, since kona and op-node should have 1:1 API specs.

Can the kona /healthz be modified to exclude the version?

We could also modify conductor to not append /healthz automatically to the rollup-boost endpoint. I think that would help in this case and reduce alot of duplicated code, that way we could configure conductor to point anywhere. Ex. /healthz/kona-boost

I would rather lean the endpoint modifiable, and modify kona to to respond with rollup-boost health somewhere else than implement a whole new client

[teddyknox]

Closing in favor of op-rs/kona#3130

[teddyknox]

Reopening in combination with op-rs/kona#3131

[jelias2]

func (c *RollupBoostClient) Healthcheck(ctx context.Context) (HealthStatus, error) {
    req, err := http.NewRequestWithContext(ctx, http.MethodGet, c.url, nil)
    if err != nil {
        return "", fmt.Errorf("failed to create request: %w", err)
    }

    resp, err := c.httpClient.Do(req)
    if err != nil {
        return "", fmt.Errorf("failed to make request: %w", err)
    }
    defer resp.Body.Close()

    // Toggle behavior here
    if c.useJSON {
        return c.parseJSONResponse(resp)
    } else {
        return c.parseStatusCodeResponse(resp)
    }
}
```

I'm curious can this PR just be boiled down to something like above?

[teddyknox]

I'm curious can this PR just be boiled down to something like above?

I can see how that's DRYer but I think it's outweighed by sticking the idiom of keeping clients and protocols 1:1. Happy to discuss however.