Adiciona comandos para criar e verificar `checksum` de arquivos

[eu-ovictor]

Sem querer acabei commitando a partir da branch do PR #159 (perdão, se souber como reverter, aceito uma ajuda)

Fixes #75

[cuducos]

Ok, parece que o commit ea7e002 é o último da outra branch. O que eu faria?

1. Branch de backup caso dê merda

Estando nessa branch downloaded-files-checksum:

$ git checkout -b downloaded-files-checksum-bkp  # cria outra branch a partir daqui
$ git checkout downloaded-files-checksum  # volta para a branch downloaded-files-checksum

2. Rebase

A ideia aqui é excluir do histórico dessa branch os commits que não pertencem a ela, ou seja, todos do e2e5731 (primeiro dela que diverge da main) até o ea7e002. No rebase, no modo interativo, a gente pode fazer isso escrevendo drop na frente dos commits que a gente não quer (ao invés de pick, que é o padrão):

$ git rebase -i e2e5731~1  # rebase, interativo a partir do último commit que queremos excluir

Aí é só trocar pick por drop nos commits entre e2e5731 e ea7e002 (incluindo esses dois). Salvar e sair e pronto.

Se der tudo certo, pode excluir a branch de backup : ) Se der tudo errado, aí exclui essa branch e renomeia a de backup!

[eu-ovictor]

Deu tudo certo 💯

[eu-ovictor]

Posso criar um canal de struct que recebe o resultado contendo a comparação e o erro. Acho válido manter o waitGroup apenas, para não termos um panic igual estava acontecendo com o comando sample. O que acha?

* a complexidade com o `notEqual struct`, mais `sync.Mutex`, mais `sync.WaitGroup` dá para ser eliminada com um uso de canais apenas (a escrita no _array_ se fora de _gorotinas_, quando recebemos coisas do canal)

Esse checksumFor no lugar do que exatamente? Não consegui entender muito bem.

* Eu tentaria algo mais [DRY](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself) como `chucksumFor(path string) []bytes` por exemplo para abstrair algumas coisas

Posso criar um diretório temporário que é uma cópia do testdata/ com os arquivos de checksum. O que acha? Eu inclui lá na pasta porque imaginei que como vamos ter arquivos de checksum para os arquivos baixados, fazia sentido eles serem parte dos arquivos de teste também.

Mas nada disso é um problema para mergear esse PR. Única coisa que é: lembra que falei que manter os arquivos do testdata/ é uma questão importante na manutenção do projeto? Não gostaria de ter que adicionar quase 20 arquivos lá. Podemos pensar em uma forma de testar que não envolva isso?

[cuducos]

Acho válido manter o waitGroup apenas, para não termos um panic igual estava acontecendo com o comando sample. O que acha?

Não precisa, pois sabemos quantos resultados esperar.

Esse checksumFor no lugar do que exatamente? Não consegui entender muito bem.

Pelo que vi da versão atual, vc entendeu sim : )

Posso criar um diretório temporário que é uma cópia do testdata/ com os arquivos de checksum. O que acha?

Pode ser. Não pensei direito nisso, mas podia ter apenas um .md5 no testdata/ para testar se (a) o checksum gerado pelo código novo bate e (b) se a comparação funciona. O resto pode ser feito num diretório temporário.

[cuducos]

Só lembre que a questão de como lidar com paralelismo e do checksumFor não era essenciais aqui : ) A gente pode refatorar depois!

[cuducos]

Sensacional, muito obrigado 💜