That's a red flag. By creating a reference of this type, you're essentially saying "this reference will exclusively lock Foo for as long as the reference inside Foo is alive, that is, for the whole Foo's existence". What's the real requirement for the lifetimes connections? Do the Foo::foo method have to accept &'a Bar and not some &'short Bar, for example?
Given this type of usage, it seems that the error is that the &'a mut Foo<'a> should be &mut Foo<'a>. The reason it needs to change was already mentioned. The reason this is the right change is because foo is only used temporarily within the function, so the mutable reference does not need to live any longer — does not need to match any named lifetime.
Lifetimes are very logical, and they don't follow excessively complicated rules. So if you have trouble with them (i.e. your code doesn't compile due to lifetime errors), then it's probably not because e.g. you don't know 50 of the 100 rules.
On the contrary: you probably just aren't aware of every place your data is borrowed from or perhaps of the exact time where some value is created. It would therefore be helpful to visualize the various regions involved in your code, e.g. by drawing some paper-and-pencil diagrams, or by annotating your lifetimes as named/labelled blocks in your code. Making constraints explicit can be of substantial help if you have trouble keeping every minute detail in your head.