Allocate fewer `PathBuf`s only to join them

[timotree3]

PR summary

Motivated by #1733

This PR mainly rewrites two patterns in the code:

• "[PathBuf] collecting"

  let path: PathBuf = [
      PathBuf::from("/tmp"),
      PathBuf::from("holochain"),
      some_path_buf_arg,
  ].iter().collect();
  

  =>

  let path = {
      let mut path = PathBuf::new();
      path.push("/tmp");
      path.push("holochain");
      path.push(&some_path_buf_arg);
      path
  };
  

• "Serial joining"

  let path = self.dir.join(foo).join(bar).join(baz);
  

  =>

  let path = {
      let mut path = self.dir.join(foo);
      path.push(bar);
      path.push(baz);
      path
  };
  

testing/benchmarking notes

( if any manual testing or benchmarking was/should be done, add notes and/or screenshots here )

followups

( any new tickets/concerns that were discovered or created during this work but aren't in scope for review here )

changelog

Please check one of the following, relating to the CHANGELOG-UNRELEASED.md

• [ ] this is a code change that effects some consumer (e.g. zome developers) of holochain core so it is added to the CHANGELOG-UNRELEASED.md (linked above), with the format - summary of change [PR#1234](https://github.com/holochain/holochain-rust/pull/1234)
• [x] this is not a code change, or doesn't effect anyone outside holochain core development

[StaticallyTypedAnxiety]

I would actually prefer the join when possible, only because pushing introduces a mutable state on variables that might not need it.

[timotree3]

In many cases I used I block here to limit mutable state. I can go through and update the rest

[timotree3]

For example, like this: https://github.com/holochain/holochain-rust/blob/f294ed3e001644448e1a816044311cc52ae3c8f8/cli/src/cli/chain_log.rs#L19-L24

Would doing them like that address your concern?

[timotree3]

@AshantiMutinta I updated this PR, now the only remaining cases where this PR introduces mutability are a few lines before the end of a test. I figure that in blocks of code that small, its easy enough to reason about either way. Does that address your feedback?

[StaticallyTypedAnxiety]

@AshantiMutinta I updated this PR, now the only remaining cases where this PR introduces mutability are a few lines before the end of a test. I figure that in blocks of code that small, its easy enough to reason about either way. Does that address your feedback?

Woops yes I am fine with this sorry for the delay

[zippy]

Hey @timotree3, this looks great. Sorry that our recent re-arrangement of the the repo into crates sub-dir requires a complex merge...

[timotree3]

@zippy thanks! I believe this is once again ready.