Provide a CSV file for the security evidence of runtime components

Make the information available together with the one provided by the Canton and Ledgers team as a CSV file bundled with every release, to which the documentation points

Currently, the TEST_EVIDENCE annotations are processed to generate the security-evidence.md file.

Either adapt the generator to (additionally) output a CSV file or move to scalatest style annotations (lib-scala/test-evidence).

Part of #14254

[stefanobaghino-da]

The idea is that of moving away from the framework built around the TEST_EVIDENCE tag to make it easier to integrate the security evidence artifacts with the ones provided as CSV by other teams. As such, the tag cannot be put freely in the source code but needs to annotate a specific ScalaTest test case, which is what creates the problem. As such, I would recommend to do one of the following:

1. if sensible within the framework of the threat modeling (which provides the framework within which a test should be annotated or not, and how – and should hence be done before any other work), slim down the annotations into one that covers them all and can go on the test case itself
2. alternatively, if feasible and not exceedingly complex and time-consuming, extend the security evidencing annotations to make sure it can be used to validate that a specific test has been run with a specific row of table-drive property based checks
3. if necessary and within the boundaries of the threat modeling, break up tests where needed and annotate them individually while balancing this act without introducing unnecessary repetition

As mentioned, any action should more or less derive from the threat modeling document for the component under test. Please note that components like the Daml engine and interpreter are under the responsibility of the Daml-LF team and @remyhaemmerle-da will work together with @soren-da to move forward with those.

@cbley-da As part of the scope that we aim to address before the end of the year are only the Ledger Clients components, which means the OAuth 2.0 Auth Middleware, the Java bindings, the HTTP JSON API service, the TypeScript bindings, the React.js bindings, and the Trigger Service (but not the Trigger Runner).

[remyhaemmerle-da]

@stefanobaghino-da I am not very queen on defactorizing, my test in order to improve generation of test evidence documentation. Repetitions make easy introduction of bugs when we need to change something and make review a very tiring task.

In this case, we can simply factorize all the test evidences in a single one, with something like :

   // TEST_EVIDENCE: Integrity: ill-formed API command is rejected