api - Refactor removal / replacement of deprecated and obsolete funcs

[Samyoul]

I've resolved a number of refactor issues in the api package.

• backend : Updated the StatusBackend interface to match usage
• backend_test : Resolved unhandled errors, import collisions and upgraded deprecated funcs
• eth_backend : resolved import collisions

[status-im-auto]

Jenkins Builds

❔	Commit	#️⃣	Finished (UTC)	Duration	Platform	Result
✖️	64ba08e	#1	2024-03-22 21:57:23	~1 min	tests	📄log
✔️	64ba08e	#1	2024-03-22 21:59:26	~3 min	linux	📦zip
✔️	64ba08e	#1	2024-03-22 22:01:50	~5 min	android	📦aar
✔️	64ba08e	#1	2024-03-22 22:02:22	~6 min	ios	📦zip
✖️	64ba08e	#2	2024-03-25 20:21:38	~1 min	tests	📄log
✖️	64ba08e	#3	2024-03-25 20:22:03	~20 sec	tests	📄log
✖️	64ba08e	#4	2024-03-26 09:53:36	~18 sec	tests	📄log

[saledjenic]

Just wondering... if this function calls func (m *DefaultManager) SelectAccount(loginParams LoginParams) error and it expects loginParams.Password to be provided, won't that return an error in case of a keycard migrated profile?

[Samyoul]

Interesting questions @saledjenic. I don't think that this change will break any existing flows.

This change only reintroduces the function signature to the StatusBackend interface. The implementation details of this function (whether loginParams.Password is expected etc) are a concern for the implementing struct.

However existing code, unaltered by this PR, that implements this function signature already uses the loginParams.Password property.

func (m *DefaultManager) SelectAccount(loginParams LoginParams) error {
	m.mu.Lock()
	defer m.mu.Unlock()

	m.accountsGenerator.Reset()

	selectedChatAccount, err := m.unlockExtendedKey(loginParams.ChatAddress.String(), loginParams.Password)
	if err != nil {
		return err
	}
	m.watchAddresses = loginParams.WatchAddresses
	m.mainAccountAddress = loginParams.MainAccount
	m.selectedChatAccount = selectedChatAccount
	return nil
}

This code is called via the LoginAccount API method. So perhaps a different API method is called when logging in via Keycard, because the failure would already be an issue without the changes in this PR.

[saledjenic]

@Samyoul yes, I see what you've changed, no problem with your change at all, I just used the opportunity to ask does that somehow affect the keycard users, nothing else, sorry about confusion. :)

[kounkou]

🚢 it, thanks @Samyoul !

[osmaczko]

Samyoul, just bumping this. The poor PR is feeling forgotten 😅

[Samyoul]

Oh no, Poor little PR . Thank you @osmaczko , I'll resolve the conflicts on merge