Reset GitlabSubscription seats when starting a new term

What does this MR do and why?

In https://gitlab.com/gitlab-org/gitlab/-/issues/334132 it was identified that customers are seeing an incorrect value for max number of seats used and subsequently seats_owed, when their subscription starts a new term (e.g. when renewing).

With the existing implementation, the max number of seats is updated daily to be the highest of either the existing max_seats_used or seats_in_use and the difference is used for seats_owed.

If a customer renews and reduces the number of seats, the existing implementation will still use max_seats_used, leading to incorrect billing information for seats_owed.

This MR seeks to address it by resetting the max_seats_used value to be the seats_in_use whenever the subscription starts a new term, i.e. when start_date and end_date are updated.

These attributes should only be updated when a new term has started, but some defensive logic has also been put in place to try and ensure this to cater for some edge cases such as transferring of namespaces.

How to set up and validate locally

1. If you don't have a SaaS subscription already, create one for a group
2. In rails console, modify the subscription data to indicate that it started yesterday and has a larger number of max seats used:

   gs = GitlabSubscription.last
   gs.update(max_seats_used: 999, seats_in_use: 1, start_date: Date.yesterday, end_date: Date.today + 1.year)

3. Trigger a reset:

   gs.update!(start_date: Date.today, end_date: Date.today + 2.years)

4. Verify it reset max_seats_used and seats_owed to the correct values:

   gs.inspect

You can now do the same process again, but changing the start_date/end_date values to a date further in the past etc.

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.