add RSS feed endpoint for querying AQ message views

[adamkorynta]

Alternate considerations:

• Looked into using a third-party RSS library for building up the XML. Seemed like the only somewhat maintained library is Rome, but that hasn't been updated since 2023 and contains the jdom2 dependency which has a known vulnerability (wouldn't really matter to our use-case of producing XML only, but would matter on the client). didn't seem too much a lift to just use our own DTO's and jackson serialization. If this ends up being a burden, it also wouldn't be too hard to update to something else in the future.
• opted to not set the atom links for self or previous as those would be moving targets given the week lookback limit. We do need a next cursor so the fact that the URL would not be reproducible after a time period is unavoidable. We could also throw out the cursor and only use the since field.
• don't search for messages older than a week. This could be shortened as needed.

[MikeNeilson]

Overall I like it. I do want to make sure that if at all practical we're exposing more standard "queue/topic" semantics.

While this will always be read only, WM staff and core developers will be interacting with the same sources of data and we should make sure things map, preferably into the future and not the past.

Will very likely be making good use of SNS and SQS for queues and topics (of which this is technically the later regardless of Oracle naming).

I'm also currently inclined towards a "queue/topic per concept" vs per-office per-concept. The latter may be an impratical amount of things to deal with when the applications can easily choose to filter and let whatever broker deal.

[MikeNeilson]

interesting trick, taking advantage of the queue persistence.

[adamkorynta]

yeah makes it so that we don't have to pull in all the aqapi and jms dependencies and keeps us from being stateful

[MikeNeilson]

Your new tests seem to be breaking, but seems like a reasonable start.