The offset-based overload hasn't been in use since f754a1a548f2e599e4cc2d1d799f2d21b520076f.
Previously, we had WBFS and CISO which both returned an upper bound of the size, and other formats which returned an accurate size. But now we also have NFS, which returns a lower bound of the size. To allow VolumeVerifier to make better informed decisions for NFS, let's use an enum instead of a bool for the type of data size a blob has.
SPDX standardizes how source code conveys its copyright and licensing information. See https://spdx.github.io/spdx-spec/1-rationale/ . SPDX tags are adopted in many large projects, including things like the Linux kernel.
Instead of comparing the game ID, revision, disc number and name, we can compare a hash of important parts of the disc including all the aforementioned data but also additional data such as the FST. The primary reason why I'm making this change is to let us catch more desyncs before they happen, but this should also fix https://bugs.dolphin-emu.org/issues/12115. As a bonus, the UI can now distinguish the case where a client doesn't have the game at all from the case where a client has the wrong version of the game.
It is my opinion that nobody should use NKit disc images without being aware of the drawbacks of them. Since it seems like almost nobody who is using NKit disc images knows what NKit is (hmm, now how could that have happened...?), I am adding a warning to Dolphin so that you can't run NKit disc images without finding out about the drawbacks. In case someone really does want to use NKit disc images, the warning has a "Don't show this again" option. Unfortunately, I can't retroactively add the warning where it's most needed: in Dolphin 5.0, which does not support Wii NKit disc images.
This is intended to catch WIA files which have been created using wit's default parameters (40 MiB block size), once the WIA PR is merged. The check does however also work for GCZ files – not that I think anyone has a GCZ file with a block size that large.
The old implementation of this was not able to distinguish between a title that had the common key index set to 1 because it actually was Korean and a title that had the common key index set to 1 due to fakesigning. This new implementation solves the problem by decrypting a content with each possible common key and checking which result matches the provided SHA-1 hash. The problem that the old implementation causes has only been reported to affect a certain pirated WAD of Chronos Twins DX (WC6EUP), but it's possible that the problem would start affecting more WADs if we add support for the vWii common key (which uses index 2). Adding support for the vWii common key would also prevent us from using the simpler solution of always forcing the index to 0 if the title is not Korean.