[DDW-1211] Update @trezor/connect to v9.0.8

[tomislavhoracek]

This PR introduces @trezor/connect library update to version 9.0.8. In the scope of this PR, we also applied Trezor voting breaking changes.

Todos

• Update @trezor/connect library to v9.0.8
• Apply Trezor voting breaking changes

Testing Checklist

• Slack QA thread
• Trezor regression testing

---

Review Checklist

Basics

• PR assigned to the PR author(s)
• input-output-hk/daedalus-dev and input-output-hk/daedalus-qa assigned as PR reviewers
• If there are UI changes, Alexander Rukin assigned as an additional reviewer
• All visual regression testing has been reviewed (assign run Chromatic label to PR to trigger the run)
• PR has appropriate labels (release-vNext, feature/bug/chore, WIP)
• PR link is added to a Jira ticket, ticket moved to In Review
• PR is updated to the most recent version of the target branch (and there are no conflicts)
• PR has a good description that summarizes all changes
• PR contains screenshots (in case of UI changes)
• CHANGELOG entry has been added to the top of the appropriate section (Features, Fixes, Chores) and is linked to the correct PR on GitHub
• There are no missing translations (running yarn manage:translations produces no changes)
• Text changes are proofread and approved (Jane Wild / Amy Reeve)
• Japanese text changes are proofread and approved (Junko Oda)
• Storybook works and no stories are broken (yarn storybook)
• In case of dependency changes yarn.lock file is updated

Code Quality

• Important parts of the code are properly commented and documented
• Code is properly typed with typescript types
• React components are split-up enough to avoid unnecessary re-renderings
• Any code that only works in main process is neatly separated from components

Testing

• New feature/change is covered by acceptance tests
• New feature/change is manually tested and approved by QA team
• All existing acceptance tests are still up-to-date
• New feature/change is covered by Daedalus Testing scenario
• All existing Daedalus Testing scenarios are still up-to-date

After Review

• Update Slack QA thread by marking it with a green checkmark

[marcin-mazurek]

Hey Tomo, well done. Please take a look at one comment around the usage of @trezor/transport :)

[marcin-mazurek]

Question - could we import from the root of the library instead?

Suggested change

	import {
	CardanoAddressType,
	CardanoCVoteRegistrationFormat,
	} from '@trezor/transport/lib/types/messages';
	import { Messages } from '@trezor/transport';

Then we could refer to the types as follows:

Messages.CardanoAddressType

Messages.CardanoCVoteRegistrationFormat

If we import from library internals that is not considered the public API, our code can break much easier even with minor/patch updates.

Second question, @trezor/transport is not listed in our package.json. It seems like a dependency of dependency. Should we add it?

[tomislavhoracek]

@marcin-mazurek

1. I totally agree with you. Done in 0d150c9
2. I think we don't need to list it since it is @trezor/connect subdependency

[tomislavhoracek]

@DominikGuzei what do you think about question / point 2 ? 🙏

[marcin-mazurek]

My point was that dependencies of dependencies are not part of public API and could also change without notice

[tomislavhoracek]

but then the types will be changed in the main / parent dependency since it is used there as well, and we will see that, right? I mean, I don't want to add one more lib if that is not necessary, and if we already have access to it. Also, I agree that is safer to list it and to use it directly. Now we should see what are pros and cons since we are using only types from it...

[marcin-mazurek]

So I just executed yarn add @trezor/transport@^1.1.4 on the branch, which added an appropriate entry to package.json but made no changes to yarn.lock. So I think it doesn't have any impact/side effect besides making it clear in package.json that it is our direct dependency. If I use yarn add @trezor/transport@1.1.4 instead (without ^ - which is our preferred way of adding dependencies to Daedalus), it adds one minor entry to yarn.lock which should not affect anything either.

It's a really minor thing though and I'll let Dominik speak now.

[tomislavhoracek]

oke then, if there is nothing added in node_modules and if it is just linked to an existing submodule, let's list it since that is a safer way.

[tomislavhoracek]

but yeah, let's hear from @DominikGuzei before the final decision :)

[DominikGuzei]

I think if we are using it directly in our code (importing) then it's better to list it explicitly 👍

[tomislavhoracek]

@marcin-mazurek @DominikGuzei done in f9fbdb9

[DominikGuzei]

Code LGTM 🚢

[gabriela-ponce]

Looks good on Windows and macOS. We need an additional QA review (in Linux, if possible)
@input-output-hk/daedalus-qa

[miorsufianiohk]

LGTM. Tested on Linux. Great job @tomislavhoracek 👍