Add out-of-date update recommendation tip

[chromatic]

This requires us to update the expected days to the next release and the date of the current release when we fixate a release. That's why the release process is updated too.

[chromatic]

I'm not sure if this is a good idea or not or if the implementation looks sensible. Comments welcome.

[patricklodder]

I think we need to split this up. I agree with introducing a release cycle. As well, although it must always remain optional to upgrade (because code defines consensus), recording it in the binary as part of the release process, measuring against it and displaying a warning when the binary is likely to be outdated could be acceptable, depending on the text.

I am however not sure that this should be a UI tip, because these tips are only displayed on Qt binaries with wallet enabled, whereas the process would be valid for all installations - including wallet disabled and headless instances. I think that the most important bugfixes and protocol updates are happening outside of wallet functionality. We have a facility that displays a warning for pre-release binaries, and I was thinking that perhaps that would be a better vehicle to extend?

[chromatic]

I like that idea. Extending GetWarnings() makes sense too; my reading of the code suggests it occurs in more places than just startup, which is why I liked the tips idea.

I'll split this into either two PRs or two commits, based on the preference of any developer who cares to comment (I have no preference). First part: just the date code in headers and release process update. Second part: user notification, including text.

[patricklodder]

First part: just the date code in headers and release process update.
Second part: user notification, including text.

This sounds like a good plan to me.

[chromatic]

I've rebased this on top of #3191 and kept the commits as structured so it's easier to review the changes. This seems like an improvement, but I have mixed feelings about the new header. Moving this to a draft so we're not tempted to merge without squash/rebase.

[chromatic]

I'm re-running the i686-win CI step because it failed at downloading a ccache deb.

[patricklodder]

Yeah - sorry I keep on restarting things if I see it fail because it's been terrible (on both bionic and focal hosts) the past month. Not sure what's up.

[chromatic]

I think this is feature complete now. Commits need squashing; is there documentation to add?

I'm also interested in feedback on my modifications to the RPC tests. I'm not convinced the implementation is wonderful, but at least it's self-contained.

[chromatic]

I've squashed and rebased.