mirrors/arti.git/crates/tor-dirmgr/src, branch arti-v0.4.0

DirMgr:: Remove Error::NoChange as redundant.

2022-05-25T12:58:37Z

Now that the relevant functions now report changed/not-changed status via a boolean out-parameter (see !527), there's no reason to have a separate NoChanged error case. Closes #484.

Merge branch 'bug482' into 'main'

2022-05-24T19:33:42Z

DirMgr: Stop load-from-cache process when there is no change. Closes #482 See merge request tpo/core/arti!527

fs-mistrust: make Mistrust have a corresponding Builder type.

2022-05-24T14:54:02Z

This is an approximately minimal revision to get Builder in place; subsequent commits will clean up the API.

DirMgr: Stop load-from-cache process when there is no change.

2022-05-24T12:50:20Z

Previously in !511 I had introduced a bug where, if there was an error more serious than "no change", that error would keep us from noticing that we had no change, and we'd loop until the safety counter ran out. Then we'd panic. This commit fixes the bug by reintroducing the `changed` boolean -- this time as an outparam for the add_from_* methods. Fixes #482.

Simplify advance and reset functions with mem::replace.

2022-05-19T12:09:05Z

Explain why we call update_status unconditionally.

2022-05-19T12:04:57Z

Remove BootstrapAction::Impossible

2022-05-19T12:00:41Z

It does nothing that Fatal does not. Suggested by @eta in review.

Fix compilation with Rust 1.56.

2022-05-17T18:58:36Z

DirMgr: Remove blocking_error return path.

2022-05-17T16:25:32Z

DirMgr: Unify error return paths

2022-05-17T16:25:32Z

We no longer have separate return paths for recoverable and fatal errors; instead, they are merged, and distinguished based on recovery actions. Since it is now possible for download() to give an error that should _not_ destroy the previous state, it takes `&mut Box`. This change unfortunately means that we can no longer call `state = state.advance()`, but instead have to do some mem::swap junk with poisoned values. Any better solution would be a good thing. Additionally, the reset() and advance() methods can no longer fail. There is still a separate return path for reset-triggering errors; I'm about to fix that.