How do you idiomatically DRY up rust code without upsetting the borrow checker?

Question

Context

Coming from OOP I'm finding as I implement various traits and functions on my structs, I want to abstract bits and pieces of them out. But whenever I do, I run into borrow checker issues. I'm looking for some advice on best rust practice. I'm open to completely changing my architecture, as part of my rust journey is to leave the OOP head space.

Problem 1

The first case I keep coming across is abstracting an implementation over all objects of a trait.

Consider this simple trait and an implementation

trait MyContainer<T>
{
    fn iter_mut(&mut self) -> impl Iterator<Item = &mut T>;
    fn check_value(&self, item: &T) -> bool;
}

struct VecContainer<T> {
    items: Vec<T>,
    checker: fn(&T) -> bool,
}

impl<T> MyContainer<T> for VecContainer<T> {
    fn iter_mut(&mut self) -> impl Iterator<Item = &mut T> {
        self.items.iter_mut()
    }
    
    fn check_value(&self, item: &T) -> bool {
        (self.checker)(item)
    }
}

So far so good. But now I have another trait I'd like my containers to implement

trait Checker<T> {
    fn check_all(&mut self) -> bool;
}

impl<T> Checker<T> for VecContainer<T> {
    fn check_all(&mut self) -> bool {
        self.items.iter_mut().all(|item| (self.checker)(item))
    }
}

Still good. But hey I notice that anything that implements MyContainer could also implement Checker... So let's abstract it over all types that implement MyContainer

impl<T, TImpl> Checker<T> for TImpl where TImpl: MyContainer<T> {
    fn check_all(&mut self) -> bool {
        self.iter_mut().all(|item| self.check_value(item))
    }
}

Here the borrow checker gets in the way, since I'm now accessing these fields through trait methods, which require borrowing self. First borrow is in self.iter_mut(), second borrow is in self.check_value(). I understand why it fails, but don't know how to do such an abstraction another way. Ideally I shouldn't have to implement Checker for every single impl of MyContainer. Any recommendations? Or is implementing on each individual implementation the rust way. Is there another way to abstract this logic?

Problem 2

The second problem I keep coming across occurs when trying to abstract methods away into helper functions. For example

// Simple trait for sake of example
trait Mutable {
    fn mutate(&mut self);
    fn compare(&self, other: &Self) -> bool;
}

impl<T> VecContainer<T> where T : Mutable {
    fn complex_check(&mut self, item1: &T, item2: &T) -> bool {
        let mut match1 = None;
        let mut match2 = None;

        for item in self.items.iter_mut() {
            if item.compare(item1) {
                match1 = Some(item);
            }
            else if item.compare(item2) {
                match2 = Some(item);
            }
        }

        if let (Some(match1), Some(match2)) = (match1, match2) {
            match1.mutate();
            match2.mutate();
            true
        }
        else {
            false
        }
    }
}

this is cool and all, but ideally I'd like to abstract that search code behind a helper method, as it cleans up the code and makes it more reusable.

impl<T> VecContainer<T> where T : Mutable {
    fn find_mut(&mut self, item: &T) -> Option<&mut T> {
        self.items.iter_mut().find(|i| i.compare(item))
    }

    fn complex_check(&mut self, item1: &T, item2: &T) -> bool {
        let mut match1 = self.find_mut(item1);
        let mut match2 = self.find_mut(item2);

        if let (Some(match1), Some(match2)) = (match1, match2) {
            match1.mutate();
            match2.mutate();
            true
        }
        else {
            false
        }
    }
}

Uh oh, again the borrow checker now is upset because I'm trying to borrow twice. For a simple example like this, it's not the end of the world. But imagine a more complex situation where I'd like to abstract a helper function. Is this just the rust way? Or is there some better way to architect it so this problem never occurs?