Merge FOSSA NOTICEs
Closes #27 (closed)
This accomplishes the "one way diff" from #27 (closed) by performing a merge of the NOTICE files during the cleaning phase. After FOSSA returns a generated NOTICE, it is merged with the existing committed NOTICE, then the combined result is cleaned (duplicates removed, entries sorted, alternate names mapped to preferred names, urls combined). This is then used as the generated-clean-NOTICE, which will be compared against the committed NOTICE in the fossa-check-notice step.
This means that the difference in the fossa-check-notice will be comparing committed+generated to committed; effectively only showing additions in the generated NOTICE.
See divido/fossa-with-cache#1 (closed) / divido/fossa-with-cache!3 (merged)
Testing
This pipeline shows the results, but many are still failing. Some are failing compilation; which I think is unrelated to anything changed in this MR. Many others are failing the fossa-check-notice, but note that the failures are all additions -- no requests to delete attributions, with one exception -- when the NOTICE contains alternate names for packages (not the "preferred" name), then it is deleted and replaced with the preferred name. In these cases, you'll see subtractions of some package names and additions of others.
Caching
The fossa-with-cache cache is designed to use old NOTICE file in lieu of a new one when the dependencies haven't changed. However, in this case, we want to use the new one because we've added a hook to merge it with the existing file. To work around this quickly, this MR disables caching of the NOTICE files, which will quickly restore all branches of all services to using the merged copy. Once merged NOTICEs have been generated on all services, we can restore the caching to get better back-to-back stabilization of the NOTICE files.
Because the NOTICE only ever adds lines, though, there is much less opportunity for a long chain of failed fossa-check-notice steps.