Look into committing the ballot receipts back into the repo

[windoverwater]

In discussions regarding the spring demo, dusted off the prior idea of checking the ballot receipts back into the repo. In the case of the spring demo this would help with the UX as the participants could scan a single QR code on the ballot-check that takes them to the csv file in GitHub. And that csv file would then contain hyperlinks to the digests as opposed to just the digests.

This would allow the participants to tap the digest link to go to their specific contest CVR content.

Though this may make for a good demo, it resurfaces the question of whether this feature is spelunk proof enough such that with all the ballot-checks in one place, could an AI or sophisticated enough data-mining program could discern something from all the ballot-checks that would compromise the anonymity, privacy, or security/trustworthiness of the election. (FWIIW things like this were/are not part of VTP if it is possible to not include them.)

Regardless this issue is about the possible implementation of the checkin for the demo.

[windoverwater]

If this is to be done, it seems reasonable to follow the same idiom as with the contest.json files, namely keep checking-in the ballot-check.csv on top of itself on a branch, and then randomly merge the branch into main as part of the ballot cache maintenance.

Minor future note - VTP wants to be able to not create a ballot check per voter request. If so, a blank ballot check should be committed so to be able to keep all the counts the same (similar to casting a blank contest).

[windoverwater]

Possible low/mid level plan which minimizes risk but while also minimizing the manual steps needed to make this idea work. Note - this plan does not modify merge-contests-operations and is focused solely on supporting the spring demo. It also does not cover mitigations against data spelunking challenges/attacks against the checked-in receipts.

• like the contest.json file, the receipt.md file is checked-in on a guid branch (from a random branch on main) but in a guid subdirectory and then sometime later is merged to main. There should be no guid conflicts as the guid test is across both branch and subdirectory in main. The guid subdir is necessary because unlike the contest.json where the content is in the commit message, for the receipt.md the content is actually file content and all the receipt.md files need to copacetically co-exist.
• a different sibling ElectionData repo is used just for receipts as it can be quite a large amount of content and files across an election
• the receipt.md file is checked-in at the end of things leveraging the same contest based sequence albeit a different repo
• add the version_receipts and demo_mode bool options to run-mock-election and vote operations which are only passed to the accept-ballot-operation call . This will allow both run-mock-election-operation and vote-operation to version the receipt.md files and print (locally store without versioning) the QR images on the receipt.csv file, a text copy of the cast-ballot, and allow someone to manually attach a sticky with the index (hand written) on it. This file (to be printed) can be .gitignore'd in the associated guid subdir to avoid collisions and more work.