Address reuse via transaction queue

[JeremyRand]

If no address reuse is occurring, we would expect all addresses to fall into one of the following categories:

1. 1 transaction; positive balance.
2. 2 transactions; 0 balance.

I'm looking at one of my testbed Electrum-NMC wallets and I'm seeing some addresses that do not meet the above expectations. AFAICT they all have the following in common:

1. Change address.
2. 3 transactions; 0 balance.
3. Both deposit transactions are name transactions.
4. The 2nd of 2 deposit transactions is a name_firstupdate transaction.

My suspicion is that change addresses are not excluded from consideration for use in a transaction if their only usage so far is in a queued transaction.

[JeremyRand]

Looking at the name_autoregister code and its dependencies, it appears that if the command is called again after a previous name_autoregister request expires (3600 seconds, i.e. 1 hour) but before the queued name_firstupdate is broadcasted (nominally 2 hours), the new request may reuse the address of the queued name_firstupdate. It looks like the fix is to inspect queued transactions in wallet.get_unused_addresses and wallet.get_receiving_keys, in the same way that both of those methods inspect the request list.

[JeremyRand]

I don't think this is limited to change addresses, but the request-based filtering probably makes non-change addresses harder to trigger this on by accident.