This removes all of the global loggers from the project and replaces them with loggers which are instantiated in vspd.go and passed down as params.
To support this, the background package was removed. It only contained one file so it was a bit pointless anyway. It only existed so background tasks could have their own named logger.
While removing the globals from background.go it also made sense to clean up the use of dcrd RPC clients. Previously two seperate clients were maintained, one for making RPC calls and one for receiving notifications. These clients have been unified.
- Rename all instances to "shutdownCtx" to be really explicit. This context is special in that it can be closed at any time without warning, so it should be obvious to the reader.
- Don't use shutdownCtx in RPC clients. Clients should not stop working immediately when shutdown is signalled, they need to keep working while the process is shutting down.
No reason for this to be a standalone func with a param when it can be a method of VspDatabase. This will be useful later when VspDatabase contains its own logger.
`CanTicketVote` doesn't really fit into the RPC client code as it is more of a business logic function. Moving it into the webapi package is more appropriate.
Running as sub-tests has the benefit of automatically logging the test name, no need to include it in failure messages manually. It even works if the test panics.
* Remove global cache variable.
Rather than maintaining cached data in a global variable, instantiate a cache struct and keep it in the `Server` struct.
* Store net params in RPC clients.
This means net params only need to be supplied once at startup, and also removes a global instance of net params in `background.go`.
- Rather than manually downloading and invoking golangci-lint, use the GitHub
action provided by the developers.
- Configure golangci with a config file rather than passing command line args.
This enables the same config to be used locally and on CI without introducing
duplication. It also allows much more flexibililty in configuration than using
CLI args alone.
GitHub is now capable of rendering mermaid.js diagrams, so we don't need to maintain a separate source and rendered .png file. The mermaid source can be embedded directly into the documentation itself.
This allows both tspend and treasury policies to be set by clients on a per-ticket basis. Preferences can be set when initially registering a ticket with `/payfee`, and can be later updated using `/setvotechoices`.
Any requests which alter treasury/tspend policy will be stored in the database using the existing accountability system.
**Note:** This does not include consistency checking, it will need to be added later when dcrwallet has an RPC to retrieve policies in batches.
vspd will now call dcrd RPC `getblockchaininfo` to determine if DCP-0010 is active, and take that information into consideration when calculating ticket registration fee.
This pulls a fix which enables vspd to determine remote client IP using header `X-Forwarded-For` or `X-Real-Ip`.
This depends on the reverse proxy setting those headers appropriately, which can be achieved in nginx 1.20 using the following:
```
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
```
This is an unfortunate workaround which is necessary because an instance of dcrwallet will only recognise a ticket as revoked if it has done the revoke itself. If another wallet broadcasts the revoke then the ticket will forever be reported as missed/expired. This causes problems for vspd when a wallet outside of the vspd deployment revokes a ticket (eg. a users ticketbuyer wallet).
I'm happy to include this slightly dirty workaround because this should no longer be an issue when the auto-revoke work in DCP-0009 lands.
This renames "Voting wallet status" to "VSP status" and it now includes the status of the local dcrd instance. This change impacts both the /admin page of the UI, and the response of the /admin/status API endpoint.
Errors generated during dcrd client creation were previously handled in middleware, and request handling was terminated immediately.
Now the error handling is delayed by adding the error details to the request context. This enables downstream handlers to decide what to do with the error.
