Account for issues created in the middle of a milestone in burndown chart

• Currently, if an issue is created in the middle of a milestone, the burndown chart considers it to have been created at the beginning of the milestone. This is a simplifying assumption. See https://docs.gitlab.com/ee/user/project/milestones/burndown_charts.html and https://gitlab.com/gitlab-org/gitlab-ee/issues/91#algorithm.
• The change here accounts for this case more explicitly, so that if an issue is created in the middle of a milestone, the chart line will move up, as expected.

Algorithm / scenarios

• Assume all dates/times are with "day" granularity.
• Assume each issue has closed_at, and it gets updated every time the issue is closed.
• Suppose I am looking at a given day, call it d, and that milestone-start-date <= d <= milestone-end-date, which we only care about for the purpose of generating the chart. Note that d has no relation to now. We can be looking at milestones in the past, present, or future.
• We only generate the chart from milestone-start-date to now.
• Suppose I am looking at a given issue i that has the associated milestone with it. I only care about issues with this milestone.
• Note that i.created_at <= i.closed_at <= now by the logic of issues. An issue can be closed and re-opened many times. But i.created_at is the first time it is open. i.closed_at stores the latest day it has been closed.

Scenario (For given d in the chart)	User-facing interpretation and assumption	Technical logic (Count/weight the issue?)
d < i.created_at	i necessarily does not exist on all of d	No
i.created_at <= d < i.closed_at	Assume i open on all of d, ignoring any possible closes and reopens in between i.created_at and i.closed_at	Yes
d = i.closed_at	i closed on d and assume it is closed on all of d	No
i.closed_at < d <= now && i.state(now) = closed	i necessarily is closed from i.closed_at until now	No
i.closed_at < d <= now && i.state(now) = open	Assume i reopened on i.closed_at + 1	Yes