Refactoring auth data to not use heapless Strings, fixing build

[ryan-summers]

This PR updates auth to:

1. Use the ConfigBuilder struct for specification to align with other start-up behaviors
2. Uses the buffer from the config to back the memory needed to cache the auth credentials, eliminating the need for heapless::String types (which impose run-time cost on users that don't need auth)
3. Excludes auth serialization without the expected feature flag to prevent accidentally providing insecure credentials.

CC @cnmozzie

[jordens]

LGTM

In practice, is it easy to keep the username and password alive long enough to meet the borrowing lifetime requirement?

[cnmozzie]

When I run cargo build --features "unsecure" it shows the error message:

Compiling minimq v0.7.0 (D:\code\rust\minimq)
error[E0308]: mismatched types
  --> src\config.rs:93:13
   |
93 |             user_name,
   |             ^^^^^^^^^ expected `&str`, found `&mut [u8]`
   |
   = note:      expected reference `&str`
           found mutable reference `&mut [u8]`

error[E0308]: mismatched types
  --> src\config.rs:94:13
   |
94 |             password,
   |             ^^^^^^^^ expected `&str`, found `&mut [u8]`
   |
   = note:      expected reference `&str`
           found mutable reference `&mut [u8]`

For more information about this error, try `rustc --explain E0308`.
error: could not compile `minimq` (lib) due to 2 previous errors

[ryan-summers]

@cnmozzie Thanks for the heads up! I fixed CI so that it builds with --all-features now to prevent this in the future and cleaned up the code :)

[cnmozzie]

@cnmozzie Thanks for the heads up! I fixed CI so that it builds with --all-features now to prevent this in the future and cleaned up the code :)

Nice, can't wait to see the new release :)

[ryan-summers]

In practice, is it easy to keep the username and password alive long enough to meet the borrowing lifetime requirement?

It sort of depends. If the username / password are hard-coded CONST in the end user application, they have a static lifetime and we don't need to keep a copy around. However, there's also the use case where credentials would be stored in EEPROM or external memory (i.e. are settable at run time). In this case, the user would read them into a stack-allocated buffer before handing them to the client. In this case, the strings would lose scope afterwards. This is why I opted for using some of the buffer the user provides to keep a copy of them around instead.