More robust handling of password null-termination and empty passwords

[kFYatek]

I experimented with my Roomba i3, attempting to initialize it without using the official iRobot app. The first thing I tried is connecting to it using the Roomba's SoftAP used for initial provisioning - and it kind of works, but it turned out the initial password was empty.

The response to the magic packet in this case was:

00000000  f0 2e ef cc 3b 29 00 00  00 00 00 b4 43 cb 77 18  |....;)......C.w.|
00000010  4b 8c 77 4c 4b 8c 77 10  6e ba 77 30 6c b6 77 05  |K.wLK.w.n.w0l.w.|
00000020  00 00 00 06 85 f6 64 50  26 a8 55 34 00 5c 55 10  |......dP&.U4.\U.|
00000030

There are a couple of null bytes starting at offset 7, followed by something that looks like garbage data. If this is supposed to be null-terminated, then the first null byte should be taken into account instead of just rstrip()ing the data. Otherwise the app fails with an UnicodeDecodeError.

While connecting via the SoftAP interface may not be very useful, this might additionally help in case of a irregularly short password.

EDIT: In the second commit, I also made the address, blid and password field validation less aggressive, so that connection via that SoftAP can be made. It's not very useful, as the network disappears after the first command - but you can order the robot to start cleaning while connected to its SoftAP network. The password is empty in that configuration, though, so the app in its current state did not allow that.

[NickWaterton]

Not sure this change is warranted. getting the password from the cloud is now the way to go since getting the password locally no longer works since the api changed.