feat: Proposal votes download

[victorgcramos]

This PR adds proposal votes downloads on politeia app-shell, and changes the approach used to fetch and integrate proposal downloads.

Changes were required after noticing that downloads were being canceled on routes changes, and since the ticketvote timestamps has an average 3h of download time on mainnet, users ended up having their navigation "blocked" in order to avoid download to be canceled.

This PR also adds the support for background downloads by adding global services handlers on our appSetup.

Closes #2864

packages/comments

• Fetch all timestamps thunk error handling;
• Comments timestamps mocks

packages/common-ui

• ProgressBar component
• Toast component (WIP ⏳ )

packages/core

• Add global services support for the app setup:
  • Now, you can add services setups to run on our app regardless its route.
• Add matcher support for app listener creators.
• Records timestamps mocks
• Progress services:
  • global/progress/init. Initializes progress counter for given payload to be used as the amount of requests expected;
  • global/progress/update. Updates progress. Each update effect adds +1 to the progress counter;
  • global/progress/end. resets the progress counter to its initial state.
• Message services:
  • global/message/set. set message title and body
  • global/message/clear. clear message title and body

packages/icketvote

• Refactor timestamps slice and thunks
• Handle batched timestamps requests
• Remove timestamps cache on app state
• Mocks for timestamps and details

apps/politeia

• E2E tests for proposal downloads
• Add pi downloads services setup & hooks
• Remove downloads references from Details page and move to a separate ProposalDownloads component
• Add ProgressBar component to global app wrapper
• Link ui/progress services to proposal downloads listeners
  • start progress when ticketvoteTimestamps/fetchAll or commentsTimestamps/fetchAll is pending;
  • update progress for every ticketvoteTimestamps/fetch or
    commentsTimestamps/fetch is fulfilled;
  • end progress when .../fetchAll requests are either fulfilled or rejected.

Preview

[victorgcramos]

@tiagoalvesdulce Moving downloads services to core package is a good suggestion. I agree with it, but I'd like to share my thoughts with you. I don't think we should handle them as a pi service, since the pi plugin is implemented by the politeia app-shell, and we don't intend to use it elsewhere. Therefore, we would have to implement (copy/paste) the download service for each other app we create.

Initially, I thought of progress to be just an "UI indicator", without much complexity around it, and this is why I didn't name it "download". This service is supposed to track the progress percentage of some external request, and not handle downloads itself. I couldn't think of a non-UI usage for this service...

As you said on your example, if we want to send an e-mail after some download finishes, we can create an "email service" to listen to our downloads, with an effect that sends you the downloaded payload.

[tiagoalvesdulce]

Yeah, I agree it's a UI service, but I think it should be available to developers outside the common-ui if they want to use another UI framework, like angular or vue to develop since this service is vanillaJs.