Finish the password-change logic

[dnwiebe]

When the password is changed from the UI, a lot of correct things happen, but not enough of them.

In general, when it receives a UiChangePasswordRequest, the Configurator actor sends a NewPasswordMessage to each of the actors listed in its new_password_subs field. That's good.

The problem is that when the Configurator receives a BindMessage, it populates the new_password_subs field with only the Neighborhood's recipient. This means that when the password changes, only the Neighborhood finds out about the change, and every other actor that needs encrypted data from the PersistentConfiguration keeps the old password. That means the Node goes crazy and has to be restarted whenever the password is changed.

Tasks:

1. Look through the PersistentConfiguration and find all the methods that require a password.
2. Find all the actors that call any of those methods.
3. Implement a handler for the NewPassword message in each of those actors, and make sure the BindMessage contains a NewPassword recipient for each of those actors.
4. In the Configurator's BindMessage handler, add those new recipients to the Configurator's new_password_subs list.
5. Write a test (probably a single-hop _integration test) that changes a Node's database password and then verifies that every actor that uses the database password is using the new password properly to access the database.

[dnwiebe]

The front-end team has already put in some code to work around the existing failures here; synchronize with them about the changes you plan to make.

[utkarshg6]

Review this comment by @bertllll while recontinuing the work on this card:

@utkarshg6 @dnwiebe Your whole assumption is wrong. You keep forgetting that the problem relates to the unique moment when the Node has been installed recently and it has its database half empty.

a) the password is missing
b) also the wallets haven’t been set (obviously, because the database doesn’t even have a password)

Now, this is the situation you should be looking at. This is the where the issue arises. Nowhere else.
Issue: when you start up the Node, the database have no wallets and thus the bootstrapping operation has to leave out collecting the wallet key information for the BlockchainBridge. The user proceeds to creating a password and then also the wallets by when we have a Node with new wallets in the database but the actor which should know about it, the BlockchainBridge, is completely unaware of it, which is wrong.

Of now, the workaround: the user shuts down the Node and starts it over which will fix the issue with the wallet information not properly loaded into the system.

Hopefully (one of the) objectives of Utkarshe’s card: To change things so that the BlockchainBridge can update its state based on receiving a message saying: hey there are new wallets down there in the database, you should know, because look at your knowledge, yours says “no wallets”, because the field is (probably) None.

Sorry Utkarsh that I didn’t explain clearly enough first time we discussed this.

[utkarshg6]

Testing Outline

Objective

Verify if Node restart is no longer needed during wallet generation/recovery when initializing a new Node with a password for the first time.

Background

Problem

In the past, when setting the password for the first time and initializing/recovering a new consuming wallet, a Node restart was required. This was because the information about new wallets wasn't communicated to the actors that needed it. As a result, users had to restart the Node to ensure that actors were informed about the new consuming wallet.

Solution

The actors (Neighborhood and the Accountant) become aware of the change through the ConfigChangeMsg.

Test Scenarios

Test Scenario 1

Step 1: Start the Node.
Step 2: Set the Password.
Step 3: Generate new wallets using generate-wallets command.
Step 4: Look at the Accountant's logs.

DEBUG: Accountant: Consuming Wallet has been updated: 0xfa133bbf90bce093fa2e7caa6da68054af66793e
INFO: Accountant: Scanning for payables

Step 5: Look at the Neighborhood's logs.

DEBUG: Neighborhood: Consuming Wallet has been updated: 0xfa133bbf90bce093fa2e7caa6da68054af66793e

Test Scenario 2

Step 1: Setup a fresh Node and set a new consuming wallet using recover-wallets command. Make sure it holds some MASQ tokens.
Step 2: Look at the Accountant's logs.

DEBUG: Accountant: Consuming Wallet has been updated: 0xfa133bbf90bce093fa2e7caa6da68054af66793e
INFO: Accountant: Scanning for payables

Step 3: Look at the Neighborhood's logs.

DEBUG: Neighborhood: Consuming Wallet has been updated: 0xfa133bbf90bce093fa2e7caa6da68054af66793e

Step 4: Browse the internet.

Step 5: Look at the blockchain explorer to see if payments were successful.

Test Scenario 3 (Optional)

Step 1: Setup a fresh Node and set a new earning wallet using recover-wallets command. Make sure it doesn't hold any MASQ tokens.
Step 2: Look at the Accountant's logs.

DEBUG: Accountant: Earning Wallet has been updated: 0xfa133bbf90bce093fa2e7caa6da68054af66793e
INFO: Accountant: Scanning for receivables

Step 3: Relay the data over the network.

Step 4: Look at the blockchain explorer to see if payments were successful.

Note: Make sure all the test scenarios pass without restarting the Node.