provides common performance tests scenarios

[dnadoba]

Add initial performance tests and make CI aware of performance tests

Motivation

We want to optimise the library and improve performance.
If want to improve performance based on numbers, we need performance tests.

Modifications

• Add a new test target for core.
• Move TestRSocket and TestUnidirectionalStream into new RSocketTestUtilities target
• Split CI testing into two jobs
  • one for normal tests which are build in debug mode
  • one for performance test which are build in release mode
• add end to end performance tests which use TCP as transport and Berkeley sockets as the underlying API

Result

We can now start looking into performance related topics and also add more performance tests

Discussion

Performance Test do not fail if they take too long. I could not find a way to generate and define a baseline.
Relevant discussion I could find from the swift mailing list (2016): https://forums.swift.org/t/performance-testing-via-swiftpm-and-xctest/3529/4
I think it is still useful to run the performance test in CI:

• Other CI jobs only build the package in debug mode and not release mode.
  • This verifies that the code compiles in release mode too i.e. with optimisations
  • Should not make a difference but actually can if there is a bug in the compiler (which happens more frequently when it should)
• Performance Tests send messages in parallel and could highlight some thread safety issues