Move JUnit rendering to ruff_db

[ntBre]

Summary

This PR moves the JUnit output format to the new rendering infrastructure. As I
mention in a TODO in the code, there's some code that will be shared with the
grouped output format. Hopefully I'll have that PR up too by the time this one
is reviewed.

Test Plan

Existing tests moved to ruff_db

[github-actions]

mypy_primer results

No ecosystem changes detected ✅
No memory usage changes detected ✅

[github-actions]

ruff-ecosystem results

Linter (stable)

✅ ecosystem check detected no linter changes.

Linter (preview)

✅ ecosystem check detected no linter changes.

Formatter (stable)

ℹ️ ecosystem check encountered format errors. (no format changes; 1 project error)

openai/openai-cookbook (error)

warning: Detected debug build without --no-cache.
error: Failed to parse examples/mcp/databricks_mcp_cookbook.ipynb:12:1:8: Simple statements must be separated by newlines or semicolons

Formatter (preview)

ℹ️ ecosystem check encountered format errors. (no format changes; 1 project error)

openai/openai-cookbook (error)

ruff format --preview

warning: Detected debug build without --no-cache.
error: Failed to parse examples/mcp/databricks_mcp_cookbook.ipynb:12:1:8: Simple statements must be separated by newlines or semicolons

[MichaReiser]

Could you add a link to the format specification?

[MichaReiser]

Given that this is a free text field, I'd prefer if we omit row and column for diagnostics without a location rather than making up a location. For the future, I could see us use the full diagnostic renderer for the description similar to https://www.ibm.com/docs/en/developer-for-zos/16.0.x?topic=formats-junit-xml-format

[MichaReiser]

Same here, I think I'd prefer not to insert a made-up line and column information if they are missing

[MichaReiser]

I know that's pre-existing but I wonder if the test case name is supposed to be unique (but it isn't if a file contains multiple diagnostics with the same code). But this isn't something that we need to solve in this PR

[ntBre]

That's a good point, it does seem like it's probably supposed to be unique. This site says it's the test method name in the test's class specified by classname.

[MichaReiser]

This has now come up a couple of times (JSON reports too).

We could write a io::Write to fmt::Write adapter instead. It's slightly less efficient because it needs to validate that the string is valid UTF8

struct FmtAdapter<'a> {
    fmt: &'a mut dyn std::fmt::Write,
}

impl std::io::Write for FmtAdapter<'_> {
    fn write(&mut self, buf: &[u8]) -> std::io::Result<usize> {
        self.fmt
            .write_str(str::from_utf8(buf).map_err(|_| {
                std::io::Error::new(
                    std::io::ErrorKind::InvalidData,
                    "Invalid UTF-8 in JUnit report",
                )
            })?)
            .map_err(io_error)?;

        Ok(buf.len())
    }

    fn flush(&mut self) -> std::io::Result<()> {
        Ok(())
    }

    fn write_fmt(&mut self, args: Arguments<'_>) -> std::io::Result<()> {
        self.fmt.write_fmt(args).map_err(io_error)
    }
}

fn io_error(error: std::fmt::Error) -> std::io::Error {
    std::io::Error::new(std::io::ErrorKind::Other, error)
}

The other alternative (but this might be worth a separate PR) is to explore if we can pass an std::io::Write instead of an std::fmt::Write

[ntBre]

Thanks, I can add this for now. I poked a bit at passing a std::io::Write to all of these formats before, but I think it would justify its own PR like you said.