Refactor: Fix: impl XX for associated type conflict in another crate

[drmingdrmer]

Changelog

Refactor: Fix: impl XX for associated type conflict in another crate

This commit addressed an issue of implementing trait for associated
types, by replacing implementation for associated type with concrete
type pb::Vote.

• Related issues: Implementations conflict when using associated type across crates rust-lang/rust#51445

• The minimized reproduce repo is:
  https://github.com/drmingdrmer/conflict-trait-in-main

Explanation:

If one crate lib.rs implements a trait(Default) for an associated
type(<() as Container>::Item, which is Foo), in another crate
main.rs, it seems the compiler treats the associated type(<() as Container>::Item) as a generic type T and assumes T would
be any type and results in the conflict with a local type that tries to
implement Default, while actually Foo and Wow are actually
different types.

▾ src/
    lib.rs
    main.rs

lib.rs:

pub trait Container {
    type Item;
}

impl Container for () {
    type Item = Foo;
}

pub struct Foo;

impl Default for <() as Container>::Item {
    fn default() -> Self { Foo }
}

main.rs:

// Make main.rs depends on lib.rs
use t_conflict::Container as _;

struct Wow;
impl Default for Wow {
    fn default() -> Self { Wow }
}

fn main() {}

cargo build yield this error:

error[E0119]: conflicting implementations of trait `Default` for type `Wow`
 --> t-conflict/src/main.rs:7:1
  |
7 | impl Default for Wow {
  | ^^^^^^^^^^^^^^^^^^^^
  |
  = note: conflicting implementation in crate `t_conflict`:
          - impl Default for <() as Container>::Item;

---

This change is