Draft: Add ChartData class

Background

To track the progress of the issues assigned to a timebox such as Milestone or Iteration, a burnup/down chart is often used and in GitLab, we have the Milestone/Iteration report feature like shown here.

In the above milestone report, three issues were assigned to the milestone on Mar 20 and one of them was completed. Similarly, if the issues have weights, we are interested in knowing how many weights have been completed. Such data points are currently generated by TimeboxReportService class. For example, for Mar 20 given some milestone (or iteration) we would have the following data point:

{
  date: Mar 20,
  scope_count: 3, # the number of issues in the milstone
  scope_weight: 10, # the sum of the weights of the issues in the milestone
  complete_count: 1, # the number of closed issues in the milestone
  completed_weight: 2 # the sum of the weights of the closed issues in the milestone
}

What does this MR do and why?

The problem is TimeboxReportService is a very complex class with many responsibilities and is hard to refactor and update.

This MR adds a new utility class ChartData that can generate data points used to plot burnup and downcharts.

• For now, ChartData won't be used by any production code but I plan to use it to shrink and refactor TimeboxReportService in a later MR.

• ChartData prevents double counting issue and its child tasks as specified in 381879#proposal.

How does ChartData work?

To generate a data point like the example shown earlier, we need to use a snapshot of the states of the issues and work items on some date for a timebox.

Here's an example snapshot.

[
  {
    item_id: 1,
    timebox_id: 2,
    weight: 3,
    start_state: ResourceStateEvent.states[:opened],
    end_state: ResourceStateEvent.states[:closed],
    parent_id: nil,
    children_ids: Set.new
  },
]

In the snapshot, we find that the item with item_id: 1 became closed and has weight 3.

The generated data point would be:

{
  scope_count: 1,
  scope_weight: 3,
  complete_count: 1,
  completed_weight: 3
}

The added specs deal with a comprehensive set of scenarios and have additional inline comments.

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

• I have evaluated the MR acceptance checklist for this MR.