Fix rpc not transferring promotion warnings to the client

[ElectreAAS]

Fixes #12578, and only looks like it fixes #12577, but doesn't, it was a red herring. See discussion on latter PR.

What was missing

• A proper way for RPC requests to return warnings encountered during build.

[ElectreAAS]

I just rebased on main. I believe I addressed your request @rgrinberg, and this is ready for a second pass

[Alizter]

I think it would be better to split the two changes here. I'm fairly certain the promotion database clearing bug has been solved here, so I think that can be reviewed and merged quickly. The warning forwarding however has some potential issues and I think need a more careful review.

[ElectreAAS]

I just did a pass, moving the warning state from a variant in Build_outcome_with_diagnostics.t to a field in Compound_user_error.t according to discussions we've had in passing. During that pass, i tried to only keep the warning changes and to not fix #12577, but according to the tests, the fix is still there, so I'm puzzled.

I tested locally and it doesn't seem to be the fold problem mentionned above (https://github.com/ocaml/dune/pull/12604#discussion_r2481153162)...

[Alizter]

@ElectreAAS in that case it sounds like there is some racy behaviour. Could you intersperse some sleep commands to make sure things are finishing before you go onto the next command? Recall that dune build connecting to a watch server may exit before the server is done doing stuff to the promotion database.

[ElectreAAS]

The fact that it looked like we solved the promotion database clearing bug was due to weird races happening. I changed the test to make it clear that we are testing the warnings, not this other behaviour.

[ElectreAAS]

We did a pass with @Alizter yesterday (thanks again btw) to not break the hashes in test/expect-tests/dune_rpc/dune_rpc_tests.ml, which required outputting a new version of the diagnostics RPC, which is rather verbose. This is necessary to maintain backward compatibility. Now the hashes aren't broken, we just have a v3. This is ready for what I hope is the final round of review

[shonfeder]

@Alizter are you OK with the state of this? Anything needed for a :heavy_check_mark:

[Alizter]

I will give it another review.

[ElectreAAS]

After some considerations, we decided that the alert parsing code didn't need to be in this PR.

[ElectreAAS]

• [x] has a changelog entry