feat: DAQ Heartbeat

[nicholasching]

Completed basic heartbeat functionality for DAQ with the following features and design considerations:

Decided to implement heartbeat on separate heartbeat.go file for modularization.

On an interval, currently 3s, send POST request to the server with the following info:

• timestamp
• vehicle_ID - currently retrieved from env variable; i was thinking this could be used as a tag to filter data in the future. For example, we can configure the vehicle with different identifiers to differentiate between development, testing, practice, competition, etc, and then filter runs by vehicle_ID
• session_ID - unique hash generated on each startup of the heartbeat script, allows us to track different test runs and associate CAN frame data w/each run, maybe some sort of list view for runs in the future.
• CAN connection state for basic debug if the CAN telemetry does not work, but heartbeat does.

If communication fails, nothing happens; we will continue sending on the same regular interval.

[sokosam]

Rest LGTM

[sokosam]

I haven't touched go in a while but can you confirm if this actually checks if the can channels are active? (assuming that this is the goal)

are we certain that if HeartbeatHandler -> can0 : net.Conn is simply initialized that it would mean its active/online?

Again I'm not really sure how this works so just lmk if its right or not.

[sokosam]

Can we name both to Interval? Feels weird to have one be uploadTimer and heartbeatInterval

Suggested change

	}
	uploadInterval := time.NewTimer(time.Second)
	heartbeatInterval := time.NewTicker(3 * time.Second)
	defer heartbeatInterval.Stop()
	for {
	select {
	case <-uploadInterval.C:
	err = telemetry.Upload()
	if err != nil {
	fmt.Printf("failed to upload telemetry data: %v\n", err)
	}
	case <-heartbeatInterval.C:
	err = heartbeat.SendHeartbeat()
	if err != nil {
	logger.Error("Failed to send heartbeat", zap.Error(err))
	}
	}
	}