Limit number of issue changes in DB

There have been a few cases where the number of changes tracked per issue is very high, taking up a large portion of the space taken by the DB. There may be hundreds or thousands of entries in issue_changes per issue. These entries are never purged and there's no "housekeeping" procedure for it.

The root cause for having so many changes is not fully understood, but we suspect that there are at least 2 causes:

• Too many moves between short living branches tracked for issues in old versions (7.9 LTS). These changes will have data including "from_short_branch".
• Cases where due to misconfiguration, different branches or projects are analyzed under the same project/branch keys, causing issues to close and reopen repeatedly. Every time an issue is closed or reopened, an entry is added to issue_changes.

Having so many issue changes not only causes the table issue_changes to take in some cases more than 50% of the total DB size, but also causes several operations to slow down.

Even in cases of user misconfiguration, SonarQube should limit the number of issue changes tracked in the DB. It's not relevant to have hundreds of changes tracked for an issue.

The exact strategy is to be defined. A few ideas:

• Only keep the last 10 latest close/reopen cycles.
• Only keep the last 5 issue moves across branches
• Always keep certain important events, such as the original creation of the issue

The cleaning up could be done in the context of an analysis, since I believe we are already loading the changes in memory. To avoid triggering a clean up in every analysis, the trigger could be higher than the threshold. For example, trim number of changes to 5 when it reaches 10.