Доработки meta4ra

http://www.meta4ra.stargrave.org/
Я стал что-то типа .meta4 fanboy-ем. В системе сборки BASS (прежде это
называлось zwoki, 7e1dbd0539c7ea5c6bd5e8831abeea4796da693e, а теперь
Build Automation Simple System) всё качается через Metalink4 файлы. Ибо
и контрольные суммы и несколько ссылок и подписи удобно лежат в одном
файле.

В пакетах я хранил только BLAKE3 контрольную сумму. Но для РФ зачастую
любой хэш отличный от Стрибога -- будет как-бы несуществующим.
Использовать его вместо BLAKE3 -- слишком медленно. Снова получается,
что нужно хранить несколько хэшей для файлов внутри пакетов.

Есть у меня места, где нужны хэши, но пофиг какие -- просто например для
сравнения файлов между собой. Был hardcode b3sum, но, опять же, в той же
Astra Linux, из коробки этой утилиты нет, а дополнительные зависимости
это всегда когнитивная нагрузка на человека. b3sum можно собрать в
пределах системы сборки и установить этот пакет. Но проблема курицы и
яйца: для создания пакета, уже нужен b3sum хэш, а чтобы его получить --
надо собрать пакет.

Такое уже было с ZStandard сжатием, но там я просто для некоторых
пакетов форсировал использование "gzip"-а. libarchive-based bsdtar
автоматически может понимать какой декомпрессор надо запускать. Вот
такое же хотелось бы и для хэшей. meta4ra-check утилита на самом деле
уже так и делает: находит первый общий хэш и его и проверяет. Нет b3sum
-- будет fallback до чего-то другого имеющегося. Когда появится после
установки пакета -- будет использован в приоритете.

Пришлось в meta4ra-check добавить -stdin опцию, чтобы можно было данные
единичного файла проверять через stdin. Добавил -all-hashes опцию,
которая форсирует проверку всех хэшей .meta4 файла, просто чтобы
убедиться что всё в нём корректно рассчитано и не бито. Добавил
meta4ra-hash утилиту, которая через stdin/stdout считает первый хэш
указанный в -hashes -- как-раз тот самый случай, когда нужен любой хэш,
желательно более приоритетный.

meta4ra использовала внешние утилиты для расчёта хэшей. Сама Go
программа использовалась только для работы с XML и распараллеленным
запуском команд хэшей. Список команд задаётся через -hashes, где через
запятую перечисляются "name:cmdline" пары, указывающие название хэша
(которое будет в XML) и командную строку для запуска. Точнее прежде был
запуск только единичной команды, а теперь это строчка передающаяся в
"/bin/sh -e -c", поэтому можно использовать и конвейеры. Но на разных ОС
доступны разные команды. Заставлять человека тщательно формировать
довольно длинную строчку описывающую что надо запускать -- геморройно.
Написал поэтому meta4ra-hashes-detect утилитку, которая просто
перебирает hard-coded известные (мне) команды для расчёта того или иного
хэша, проверяя их работу напротив hard-coded хэша от "hello world".
Теперь можно любую команду запускать типа:
    meta4ra-check -hashes "`meta4ra-hashes-detect`" ...

Когда-то сам meta4ra считал хэши. Но реализации в Go не всегда
удовлетворительно быстрые. Поэтому я и стал использовать внешние
команды. Однако, если на скорость пофиг и хочется хоть как-то посчитать,
например при создании установочных пакетов? А потом уже использовать
появившуюся быструю b3sum/Skein/Стрибог/whatever? Решил поэтому вернуть
возможность использования, так называемых, builtin хэшей, но компилируя
их опционально. Если просто собрать meta4ra "go build"-ом, то будут
использованы только родные библиотеки, где только sha256/sha512. Если
указать "tags thirdparty", то будет использована масса дополнительных
библиотек для кучи остальных хэшей. vendor-ized tarball все их содержит.
Для использования builtin реализации надо указать "builtin" в качестве
cmdline строчки.

Ради Python пакетов, которые теперь на PyPI по умолчанию хэшируются
BLAKE2b, добавил BLAKE2b. Всё же он очень распространён. А BLAKE2s
только внутри протоколах, как правило, используется. Его не стал.
Однако, PyPI использует не просто BLAKE2b, а BLAKE2b-256, хэш которого
не просто обрезанный полный 512-бит. Поэтому добавил ещё и BLAKE2b-256.
Оказалось, что b2sum утилита также входит и в GNU Coreutils (но это не
та, что официально поставляется авторами BLAKE2, но "-l" аргумент
работает одинаково у них обеих). BLAKE2b-256 на PyPI встречается в URL-е
для скачивания пакета.

Убрал Skein-256, смысла в котором и нет. Авторы Skein рекомендуют
ориентироваться на Skein-512. Ну и github.com/dchest/skein библиотека
только его и поддерживает (реализации dchest-а доверяю). Ну и Skein-512
на 64-бит системах ощутимо быстрее работает.

Добавил XXH3-128 (dffa894abeab4eaec509b95af9d23b51e4e0f844). Ну
just-for-fun. С другой стороны, для проверки целостности его 128-бит
значение вполне себе годно, если модель угроз не включает в себя
злоумышленника, а только ошибки канала связи. Go реализация XXH3 тоже
очень быстра.