feat:miner:harmonytask

[snadrus]

Related Issues

HarmonyTask implementation (PR attempt 2)

Proposed Changes

HarmonyTasks package and Resources package to manage tasks.

Additional Info

Tasks are listed in Yugabyte and competed-for through a greedy (but not too greedy) algorithm that enables tasks to hop from creator-machine to consumer machine or even from task-completion-machine to following-task-defined-elsewhere-machine.
See doc.go
Overview in https://docs.google.com/document/d/1lPe-6HdVe_oU0mD29f9Zi4233_xhSbyiXxM_6zXG4hY/edit#heading=h.k4h9btwn9p1y

[magik6k]

The other PR: #11108

[snadrus]

@magik6k Please review this one. The other somehow pulled-in feat/sturdypost so was abandoned.

[magik6k]

This is really starting to look like code that is going to be actually in-use in production in near-ish future. Couple of comments, and definitely can't wait to see stuff implemented on top

[snadrus]

Please review again. The def_test (test_unit_node) issue is something Shrenuj has addressed elsewhere (it's in the dest branch). I don't think the extern issue (test_unit_rest) is from this work.

[shrenujbansal]

Looking at the wdpost task generation logic, I'm a little concerned that the Task Interface framework doesn't quite fit the bill and there has to be a non significant amount of work done to make it fit

[shrenujbansal]

How was the case with concurrent tasks inserting and taking a task tested?

[shrenujbansal]

I'm happy to just get this merged in our branch since this is additive code and iterate further on it as we see fit. Unless @magik6k wants to see any more changes to this

[magik6k]

First pass, I feel like I'm starting to get a pretty good intuition of how this works.

There will probably be a number of edge-cases that we will discover as we exercise this logic, but to do that we need to start actually building on top of it.

[magik6k]

Most places use snake_case for naming files, so this could be task_type_handler.go