refactor replica migrate size moveCost

[qoo332001]

此PR將計算搬移資料量成本拆分成"移入"與"移出" ，如此才能表示"實際需要搬移的資料量"，若是這支沒問題，未來也會把ReplicaLeaderCost,ReplicaNumberCost改成類似的形式

舉個例子:
一個broker在一個搬移計畫中移出5GB且移入3GB，原本的計算方式看到的成本會是 -5+3 也就是只能看到此broker的搬移成本為移出2GB，沒辦法實際得知移出多少以及移入多少，這會導致在估計搬移時間上有誤差

[chia7712]

此PR將計算搬移資料量成本拆分成"移入"與"移出" ，如此才能表示"實際需要搬移的資料量"，若是這支沒問題，未來也會把ReplicaLeaderCost,ReplicaNumberCost改成類似的形式

不好意思，想先回頭討論一下這個題目：

現有的ReplicaLeaderSizeCost和RecordSizeCost看資料的角度是只看各個節點身上有多少的"record size"變化，跟資料進出無關，就算某個節點實際上是從 tp-0 變成 tp2-1 完全不一樣的配置，只要兩者的資料大小一樣cost就會是0。這樣的目的是要追蹤在該節點上“record size"的配置量的差異，而非“資料進出量”

所以在我的想象中，這個題目跟ReplicaLeaderSizeCost和RecordSizeCost目前處理的東西是不同的東西，我們可能要先思考一下上述那段要處理的東西是否需要保留？ 我覺得你這邊提的東西蠻合理，比起上述那段更能反應“搬移成本”，所以或許上述那段可以直接拿掉，這樣也可以簡化。

另外一個要討論的則是這個題目討論的東西是否更適合放到NetworkEgressCost/NetworkIngressCost? 這兩隻看事情的角度才是流量、ReplicaLeaderSizeCost/RecordSizeCost看的則是“儲存的資料量"

[qoo332001]

所以或許上述那段可以直接拿掉，這樣也可以簡化

或許這邊可以把ReplicaLeaderSizeCost和RecordSizeCost的MoveCost都移動到獨立的CostFunction，因為原本的邏輯是"限制搬移計畫record size的變化"，這樣的限制感覺是沒有意義的，感覺要是"限制搬移計畫移動的log資料量"比較有意義一點

另外一個要討論的則是這個題目討論的東西是否更適合放到NetworkEgressCost/NetworkIngressCost?

或許可以建立一個新的CostFunction來做這些事情? 因為這也是在計算資料量，而不是網路流量

[chia7712]

或許這邊可以把ReplicaLeaderSizeCost和RecordSizeCost的MoveCost都移動到獨立的CostFunction，因為原本的邏輯是"限制搬移計畫record size的變化"，這樣的限制感覺是沒有意義的，感覺要是"限制搬移計畫移動的log資料量"比較有意義一點

同意，原本的限制意義不大，可以直接改ReplicaLeaderSizeCost/RecordSizeCost的邏輯，不過要討論的另一個點是“資料的進出”是否需要分開看和分開限制？

[qoo332001]

不過要討論的另一個點是“資料的進出”是否需要分開看和分開限制？

資料的進出是需要分開計算的，主要是要分別算出移出/移入需要花多少時間，而分開限制移出或移入的資料量似乎是沒有必要的，這隻PR的邏輯是計算移入/移出總量找大值當移動的log size

[chia7712]

LGTM