Sync dates back to epics when rolling up from milestone changes

What does this MR do and why?

Sync dates back to epics when rolling up from milestone changes

TODO

• Add FF to the Epics::UpdateDatesService
  • Only update the legacy epics dates if we're not using WorkItems. This way we'll trust that the sync from the WorkItems->Epics is working properly
• Add check for the due/start dates is fixed to the update query
  • To avoid updating work_item_dates_sources tables with inherited dates where it's not needed
• Add check for work_item children type
  • To avoid fetching dates from nested Tasks or something like that.
• Only fetch dates from child work item type Epic
  • To keep consistency with the current legacy epic behavior to avoid breaking the Legacy Epics Rest API
• Rename the CTE from issues to anything else
  • This will avoid extra-filters on internal queries

Related to: https://gitlab.com/gitlab-org/gitlab/-/issues/474034

SQL Queries

• ee/app/finders/work_items/widgets/rolledup_dates_finder.rb: https://postgres.ai/console/gitlab/gitlab-production-main/sessions/30496/commands/94528
• ee/app/services/work_items/widgets/rolledup_dates_service/hierarchies_update_service.rb
  • dates_source.where(start_date_is_fixed: false).update_all: https://postgres.ai/console/gitlab/gitlab-production-main/sessions/30496/commands/94532
  • update_synced_epics: https://postgres.ai/console/gitlab/gitlab-production-main/sessions/30496/commands/94536

MR acceptance checklist

Please evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Screenshots or screen recordings

Screenshots are required for UI changes, and strongly recommended for all other merge requests.

Before	After

How to set up and validate locally

Numbered steps to set up and validate the change are strongly suggested.