Refactor unblinded tokens

[tmancey]

Resolves brave/brave-browser#16005

Submitter Checklist:

• I confirm that no security/privacy review is needed, or that I have requested one
• There is a ticket for my issue
• Used Github auto-closing keywords in the PR description above
• Wrote a good PR/commit description
• Added appropriate labels (QA/Yes or QA/No; release-notes/include or release-notes/exclude; OS/...) to the associated issue
• Checked the PR locally: npm run test -- brave_browser_tests, npm run test -- brave_unit_tests, npm run lint, npm run gn_check, npm run tslint
• Ran git rebase master (if needed)

Reviewer Checklist:

• A security review is not needed, or a link to one is included in the PR description
• New files have MPL-2.0 license header
• Adequate test coverage exists to prevent regressions
• Major classes, functions and non-trivial code blocks are well-commented
• Changes in component dependencies are properly reflected in gn
• Code follows the style guide
• Test plan is specified in PR before merging

After-merge Checklist:

• The associated issue milestone is set to the smallest version that the
  changes has landed on
• All relevant documentation has been updated, for instance:
  • https://github.com/brave/brave-browser/wiki/Deviations-from-Chromium-(features-we-disable-or-remove)
  • https://github.com/brave/brave-browser/wiki/Proxy-redirected-URLs
  • https://github.com/brave/brave-browser/wiki/Fingerprinting-Protections
  • https://github.com/brave/brave-browser/wiki/Brave%E2%80%99s-Use-of-Referral-Codes
  • https://github.com/brave/brave-browser/wiki/Custom-Headers
  • https://github.com/brave/brave-browser/wiki/Web-Compatibility-Exceptions-in-Brave
  • https://github.com/brave/brave-browser/wiki/QA-Guide
  • https://github.com/brave/brave-browser/wiki/P3A

Test Plan:

• Confirm tokens are refilled after successfully fetching issuers from GET /v1/issuers
• Confirm tokens are refilled after successfully redeeming a token
• Confirm tokens are refilled after failing to redeem a token redeeming a token
• Confirm users are rewarded for viewing ads
• Confirm tokens are cashed-out
• Confirm creativeType (i.e. ad_notification, new_tab_page_ad, inline_content_ad or promoted_content_ad) is not included in the payload when tokens are cashed-out
• Confirm issuers are rejected if any payment issuer has more than two public keys with the same value
• Confirm issuers are rejected if the payment issuer is missing from GET /v1/issuers/ endpoint
• Confirm issuers are rejected if issuers have not changed since the last update
• Confirm issuers are fetched from GET /v1/issuers/ endpoint on browser launch
• Confirm issuers are fetched when ads are enabled
• Confirm issuers are not fetched when updating the catalog
• Confirm issuers are fetched every x milliseconds (see ping in GET /v1/issuers/ response)
• Confirm "like" button (thumbs up) on 30-day ads history sends an upvote confirmation to the server
• Confirm "dislike" button (thumbs down) on 30-day ads history sends a downvote confirmation to the server
• Confirm "save" button on 30-day ads history sends a saved confirmation to the server
• Confirm "mark as inappropriate" button on 30-day ads history sends a flag confirmation to the server
• Confirm clicking an ad sends a click confirmation to the server
• Confirm converting an ad sends a conversion confirmation to the server
• Confirm landing an ad (transferred) sends landed a confirmation to the server
• Confirm unblinded_payment_tokens node in confirmations.json is migrated to include ad_type (empty string), confirmation_type (empty string) and transaction_id (random v4 UUID)
• Confirm viewed ads are shown within 30-day ads history
• Confirm issuers are persisted in confirmations.json
• Confirm unblinded_payment_tokens node in confirmations.json has ad_type, confirmation_type and transaction_id for new entries
• Confirm catalog is downloaded from GET /v9/catalog endpoint

NOTE: Failed to get issuers will be shown after upgrading because the issuers node will only be created after successfully downloading issuers from GET /v1/issuers/ for the first time. See the spec for more detail

[tmancey]

CI failing due to unrelated reasons (Storybook)

[tmancey]

CI failed during the upload of binary. Unrelated