Add more integration-test tests

[jakoschiko]

We need to write tests using the integration-test framework introduced in #114.

• crtl_relaxed is true, \n can be parsed (Change default for crlf_relaxed to false #133)
• ctrl_relaxed is false, \n causes malformed (Change default for crlf_relaxed to false #133)
• literal was accepted (test: Add literal tests #119)
• literal was rejected (test: Add literal tests #119)
• literal with non-sync (test: Add tests for non-sync literals #230)
• idle accepted (test: Add tests for IDLE #218)
• idle rejected (test: Add tests for IDLE #218)
• authenticate accepted (test: Add tests for AUTHENTICATE #227)
• authenticate rejected immediately (test: Add tests for AUTHENTICATE #227)
• authenticate rejected later (test: Add tests for AUTHENTICATE #227)
• does not panic if functions are called randomly delegated to tests: Random testing #232
• server and client send in parallel, see Deadlock due to "send before receive" #134 (test: Add test for sending messages in parallel #231)

For each case we need to consider whether we want to test client, server, or both.

[jakoschiko]

arbtest looks like a good candidate for tests with random data.

[duesee]

Uuuuh, looks nice.

[jakoschiko]

Hmm, I'm not happy with arbtest. I wasn't able to generate Vec<Vec<u8>> with significant lengths. See this example.

use arbtest::arbtest;

fn main() {
    arbtest(|u| {
        let x: Vec<Vec<u8>> = u.arbitrary()?;
        println!("{x:?}");
        Ok(())
    })
    .budget_ms(1000)
    .size_min(100000)
    .size_max(100000000);
}

produces

[]
[[]]
[]
[[156], [215], [19, 242, 169], [52, 80]]
[]
[[], [187], [188, 201], []]
[[254]]
[[67, 103, 177, 41], [248, 238, 176]]
[]
[[46], [64, 132, 79, 59, 79], [], [], [235], [], []]
[]
[[112]]
[]
[]
[]
[]
[[], [87, 206], [233], [], []]
[]
[]
[]
[[50]]
[]
[[], []]
[[234], [46, 49]]
[]
[[11]]
[[191], [], [76, 242, 1]]
[[]]
[]
[[37]]
[]
[]
[]
[]
[]
[]
[]
[]
[[], [], [], []]
[]
[]
[[]]
[[38, 136, 103], [10]]
[[], [221]]
[]

Quite disappointing for 1s runtime and 100000 min bytes. Not sure if I'm doing something wrong.

[duesee]

Hm... What happens if you put an assert!(x.len() < 500) after the println? Hm... nothing.

[jakoschiko]

You can see all (!) generated values in my comment.

[jakoschiko]

My conclusion: arbtest is inherently flawed and we shouldn't use arbitrary for property testing.

arbitrary expects that it is used with some kind of feedback loop for its Unstructured. All collections are generated using this Iterator for generating elements:

impl<'a, ElementType: Arbitrary<'a>> Iterator for ArbitraryTakeRestIter<'a, ElementType> {
    type Item = Result<ElementType>;
    fn next(&mut self) -> Option<Result<ElementType>> {
        let keep_going = self.u.arbitrary().unwrap_or(false);
        if keep_going {
            Some(Arbitrary::arbitrary(&mut self.u))
        } else {
            None
        }
    }
}

If Unstructured is just random bytes, then the collection is very short with a high probabilty. And arbtest is using random bytes. I don't see how arbtest could fix that without mutating into a full-fledged fuzzing tool.