Bubble init_send_tx error instead of unwrapping

[trevyn]

Fixes #582 "grin-wallet crashes when attempting to send amount larger than balance":

$ grin-wallet send -e -m 220.5
Password: 
Wallet command failed: LibWallet Error: Not enough funds. Required: 220.512000000, Available: 0.000000000
$

cargo test --all passes locally.

[trevyn]

Oof, that's a weird one. Maybe triggered because something exited with an error where it used to panic. Will look into it.

Os { code: 5, kind: PermissionDenied, message: "Access is denied." }', controller\tests\common\mod.rs:80:38

grin-wallet/controller/tests/common/mod.rs

Lines 77 to 82 in f7c65c7

	pub fn clean_output_dir(test_dir: &str) {
	let path = std::path::Path::new(test_dir);
	if path.is_dir() {
	fs::remove_dir_all(test_dir).unwrap();
	}
	}

---- wallet_self_send stdout ----
thread 'wallet_self_send' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 5, kind: PermissionDenied, message: "Access is denied." }', controller\tests\common\mod.rs:80:38
stack backtrace:
   0: std::panicking::begin_panic_handler
             at /rustc/cb75ad5db02783e8b0222fee363c5f63f7e2cf5b\/library\std\src\panicking.rs:493
   1: core::panicking::panic_fmt
             at /rustc/cb75ad5db02783e8b0222fee363c5f63f7e2cf5b\/library\core\src\panicking.rs:92
   2: core::option::expect_none_failed
             at /rustc/cb75ad5db02783e8b0222fee363c5f63f7e2cf5b\/library\core\src\option.rs:1268
   3: core::result::Result<tuple<>, std::io::error::Error>::unwrap<tuple<>,std::io::error::Error>
             at /rustc/cb75ad5db02783e8b0222fee363c5f63f7e2cf5b\library\core\src\result.rs:973
   4: self_send::common::clean_output_dir
             at .\tests\common\mod.rs:80
   5: self_send::wallet_self_send
             at .\tests\self_send.rs:147
   6: self_send::wallet_self_send::{{closure}}
             at .\tests\self_send.rs:141

[trevyn]

Ok, it looks like that Windows CI failure was spurious — there's a widely-used crate called remove_dir_all that mentions a possible cause:

// On Windows it is not enough to just recursively remove the contents of a
// directory and then the directory itself. Deleting does not happen
// instantaneously, but is delayed by IO being completed in the fs stack.
//
// Further, typical Windows machines can handle many more concurrent IOs
// than a single threaded application is capable of submitting: the
// overlapped (async) calls available do not cover the operations needed to
// perform directory removal.

• We could use that crate for more robust handling
  or
• We could ignore errors in fs::remove_dir_all (it's only cleaning up after tests)
  or
• We can merge this as-is and leave the flaky test for later. :)

[quentinlesceller]

Looking good 👍 For the Windows CI we have indeed issues since a while. We can open an issue and track it.

[quentinlesceller]

Should we go ahead and merge this @trevyn ?

[trevyn]

@quentinlesceller Yep!