Including the miner itself in the wdPoSt scheduling

[strahe]

The current design of wdPoSt involves the miner performing all tasks by itself if no worker is available.

lotus/storage/sealer/manager_post.go

Lines 21 to 27 in 8347235

	if !m.disableBuiltinWinningPoSt && !m.winningPoStSched.CanSched(ctx) {
	// if builtin PoSt isn't disabled, and there are no workers, compute the PoSt locally
	log.Info("GenerateWinningPoSt run at lotus-miner")
	return m.localProver.GenerateWinningPoSt(ctx, minerID, sectorInfo, randomness)
	}
	return m.generateWinningPoSt(ctx, minerID, sectorInfo, randomness)

However, there is a consideration for a situation where a larger miner restarts and the worker is not yet connected. In this case, the miner proceeds to perform the tasks on its own.

However, the performance of the miner itself may take a long time, leading to a potential delay and missing the task execution window. Even if the worker is connected at that time, the tasks will not be assigned to it.

Perhaps we should consider including the miner itself in the wdPoSt scheduling or allowing it to choose to generate one by one. This way, the miner could potentially handle some tasks, while the majority of tasks would still be assigned to the reconnected workers.

lotus/storage/sealer/manager_post.go

Line 187 in 8347235

p, sk, err := m.generatePartitionWindowPost(cctx, spt, ppt, minerID, int(partIdx), sectors, randomness)