Publish Timeboost BlockMetadata to Sequencer Coordinator's redis

[ganeshvanahalli]

With this PR, the Timeboost information of transactions of a block represented as BlockMetadata (introduced in #2695) will be published to the Sequencer Coordinator redis cluster. Enabling sequencers that are part of this cluster to retrieve BlockMetadata corresponding to a block (when they attempt to sync up new messages from redis).

Resolves NIT-2839

[Tristan-Wilson]

Looks pretty solid, just some comments about error handling.

[Tristan-Wilson]

This should distinguish missing data, which I think is legitimate since we might not have metadata, from another error from the redis client like missing data.
Something like:

   if err != nil {
        if errors.Is(err, redis.Nil) {
            // Legitimate case of no metadata
            return nil, nil
        }
        // Real error reading from Redis
        return nil, fmt.Errorf("failed reading block metadata: %w", err)
    }

Then in update() you can add error handling matching the existing error flow for messages:

    metadata, err := c.blockMetadataAt(ctx, msgToRead)
    if err != nil {
        log.Warn("coordinator failed reading block metadata", "pos", msgToRead, "err", err)
        msgReadErr = err // Use existing error flow
        break
    }
    blockMetadataArr = append(blockMetadataArr, metadata)
    msgToRead++

This will ultimately cause a retry

	if (wantsLockoutErr != nil) || (msgReadErr != nil) {
		return c.retryAfterRedisError()
	}

[ganeshvanahalli]

I agree. Fixed it

[Tristan-Wilson]

I think this should be an error return here. Even if there's no metadata, blockMetadataArr should be an array of nils the same size as messagesWithBlockInfo.

[ganeshvanahalli]

This isn't the case when InboxTracker adds messages to the batch

nitro/arbnode/inbox_tracker.go

Lines 826 to 830 in 9a85c95

	// This also writes the batch
	err = t.txStreamer.AddMessagesAndEndBatch(prevbatchmeta.MessageCount, true, messages, nil, dbBatch)
	if err != nil {
	return err
	}

in which case len(blockMetadataArr) is zero but we should accept that as a correct input. Similarly a bunch of cases with invoking of AddMessages function of txStreamer.

But I agree that we should return an error here instead of just logging, because in normal conditions wrt blockMetadataArr (when called from seq-coordinator) what you said is absolutely true

[Tristan-Wilson]

Forgot to click request changes.

[Tristan-Wilson]

LGTM