feat: added notifications for validators opted in

[Mikelle]

Describe your changes

This PR introduces scheduling notifications for validator opt-ins, and running periodic epoch-based processing.

1. Notifications Module Minor Update

Topic Update

In p2p/pkg/notifications/notifications.go, a small addition was made (e.g., to support additional notification topics such as TopicValidatorOptedIn).

2. Validator Service Enhancements

Service Initialization

In p2p/pkg/rpc/validator/service.go, the NewService function has been refactored to:

• Return an error along with the service instance.
• Accept an additional notifier parameter to manage notifications.

Genesis Time Fetching

The service now fetches the genesis time from the Beacon API (/eth/v1/beacon/genesis). This timestamp is crucial for calculating slot start times.

Notification Scheduling

A new method, scheduleNotificationForSlot, has been implemented. It:

• Computes the start time of a slot based on the fetched genesis time and a defined slot duration.
• Schedules a notification to be sent before the slot starts (using a configurable notify offset).
• Sends a notification via the provided notifier, including key details such as epoch, slot, and BLS key.

Epoch Processing & Cron Job

• The processEpoch method now processes proposer duties, checks each validator’s opt-in status, and schedules notifications accordingly.
• A new Start method runs a background cron job that:
  • Calculates the upcoming epoch based on the genesis time and epoch duration.
  • Waits until the appropriate time (using a configurable fetch offset) to fetch and process the epoch.
  • Logs the scheduling and processing of epochs.

Checklist before requesting a review

• I have added tests that prove my fix is effective or that my feature works
• I have made corresponding changes to the documentation

[aloknerurkar]

I think for testing, we can follow the same approach as we did for the relay-emulator. We can add the APIs to the relay emulator or create a new beacon emulator and always return validators that are opted in. One additional thing would be that we might need to deploy the middleware contract and register some dummy public keys. The keys we register should be the ones returned from our API.

[aloknerurkar]

Nice!

[aloknerurkar]

I think for the clients it would be better to give the execution block number in the notification as they will bid on that. Can we somehow compute this? Or maybe some API which can provide this?

[aloknerurkar]

I dont think we need this delay. We already have the delay to query the duties. I think we can send this as soon as we get the info. In case of the notifications, users will be always subscribed ideally. So sooner they get it, sooner they can decide to bid.

If they miss this, they should be able to query the get validators endpoint right?