Expose the caller's specifed key size in ConnectionRequest

[pierceforte]

Currently, it is not possible to retrieve the caller's specified key size when handling a ConnectionRequest.

This means we must defer to the library to handle the key size. This presents a number of issues:

1. The library cannot currently handle key size mismatches (Implement key size mismatch #195).
   • This is especially problematic because it means one caller's bad request can shut down the server and drop all other callers' connections.
2. The library does not currently handle rejection properly (Handle server rejection properly #196), which involves rejecting on the basis of the passphrase and its corresponding key size.
3. The server implementation cannot retrieve the key size despite it being advertised in the caller's request. This prevents any custom handling of the key size.

---

This PR adds a key size field to the ConnectionRequest type, which serves as a workaround for 1 and 2 and a solution for 3.

It also includes:

• a simple test
• an example multiplex server that enforces password authorization and prevents key size mismatch errors

[robertream]

Thank you! This is a great improvement. I can help you get this merged too. Two things though:

1. the build is broken, though it's not your fault. I have a PR that hopefully fixes this: fix build failures and warnings and clippy #217
2. I appreciate the integration test coverage, and for this behavior a unit test in the protocol library is preferable for two reasons:

• simple errors in logic are often better covered by fast isolation tests vs. much slower integration tests. Faster feedback cycles during development are desirable
• testing at the protocol level provides coverage for all possible uses of the protocol (e.g. tokio vs c API, etc.)

Once the build is fixed, I'll get your changes merged. If you'd add a unit test as well, I'd appreciate that, but I won't block merging your PE on this.

[robertream]

Ok, the macos build is failing, because of c library compilation failures, but we can deal with that later.

[robertream]

You can quickly and easily run both clippy and fmt locally to avoid the CI build failures

[pierceforte]

@robertream Hi, thank you for your help. I'll add the unit test later today – we can wait to merge until that's in.

Oddly, I'm not able to see these clippy warnings or correct the formatting with the cargo commands.

The clippy command seems to be getting stuck on the macos issues.

[robertream]

These integration test failures we are seeing in CI here are the precise reason why I prefer determinist isolation tests ("unit tests") to non-deterministic integraion tests for coverage of determinist logic.

[pierceforte]

Hi @robertream, I updated the PR to remove the integration test and instead include a unit test. Please let me know if it looks ok.

[pierceforte]

Hi @robertream, can you please cut a release once the macos build is fixed? Also, is there anything I can do to help with the fix?