Add an ITicketCommentProvider interface

[Ryan J Ollos]

The design of the CommitTicketUpdater makes it difficult to retroactively add changeset comments (#11478). CommitTicketUpdater comments added retroactively are not likely to be in the correct chronological order. It would be difficult to remove CommitTicketUpdater comments if it's later decided to use a plugin such as ​TracTicketChangelogPlugin instead of having the changeset comments inline in the ticket changelog. The repository links are no longer correct if the repository name is changed (although this is generally true for TracLinks to the repository).

I've also used the ​Jenkins Trac Publisher Plugin which has similar issues.

I've considered another approach.

• Add an ITicketCommentProvider interface, that returns a comment along with a timestamp and possibly some other metadata. The ticket changelog would be created from data provided by ITicketCommentProvider implementations.
• One of the ITicketCommentProvider methods could be get_comment_filter, so that it would be possible to have a filter such as Show changesets or Show build results.
• The full history of a ITicketCommentProvider source would be available upon activating the plugin, and the comments would have the correct chronological ordering.
• CommitTicketUpdater would create a table associating tickets with changeset. As an aside, the table would also be useful for ​th:#12621.
• CommitTicketUpdater would provide comments through an implementation of ITicketCommentProvider.

One difficult aspect might be, on activating the plugin it might be desired to remove all previous instances of comments containing CommitTicketReferenceMacro instances. This could be done in an upgrade script, or through a script provided in contrib.

[Ryan J Ollos]

A potential issue I've considered is that we use integer comment ids (cnums) to link to comments using TracLinks, so on activating the plugin in a Trac installation with existing issue we wouldn't want to renumber the existing comments by interleaving the changesets messages. A way around that could be to use ids like #changeset:<r> for the changeset comments, where r is changeset identifier (integer in SVN or first 8 chars of a hash in Hg or Git), on the comments provided by the commit_updater. This has backward-compatibility challenges like the one mentioned in the end of comment:description.

If the changes were implemented, we might want to leave commit_updater as a legacy implementation, and add a completely new implementation. We could have them work together by having a start timestamp, and only changesets younger than the timestamp would be rendered using the new commit updater plugin.