The four follow-ups from !462.
- Restart:
httpd.Server.Stopandsshd.Server.Stopclose a channel that the follows run under; gitbayd calls both before the drain, so the drain waits only for work that finishes. Other requests, git transport included, are untouched.Ctx.Stoppinglets a follow ended by a restart say so on stderr ("gitbay is restarting; follow the build again in a moment"); ssh, the build page and the API all carry that message, and an ordinary failure during the drain says nothing about a restart. - Access: every 2 s a follow re-checks read access by repository id (a rename does not end it) and reloads the account (disabling it does). Losing access ends the follow as not found.
- Reads: after a wake the follow waits 200 ms before reading, so a burst of appends costs one read of the stored log.
- Tests: the first
internal/sshdunit tests (a closed session channel ends a follow while the connection stays up;Stopends one with the message; a plain failure duringStophas no message), control tests for lost access, a disabled account and the restart message, and an e2e test that SIGTERMs the daemon during an ssh and a web follow. e2equeueBuild/claimBuildhelpers extracted.
Closes #251