gov: Restructure decred's Agendas and Proposals governance implementations

[dmigwi]

This introduces two pages under /proposals and /propasal/{id} url paths. The proposals data is sourced from politeia's API endpoints and stored in the storm db as the other high level on-chain agenda details

Proposal Page

Proposals Page

[buck54321]

This is great @dmigwi . I've been looking forward to seeing Politeia data incorporated. This is important information that demonstrates one of Decred's strongest features. A couple of suggestions from the first impression.

1. The proposals page should say "Politeia" somewhere. It might even be good to have a one or two sentence description of what Politeia is. "Off-chain" is also maybe a little misleading because Politeia is anchored to the blockchain, and that's one of its most exciting features.

2. Let's pull the vote counts out of the table and give them some visual prominence. Maybe even move them towards the top. Other's might say otherwise, but I don't think we need all three columns that basically say the same thing. Maybe just "Approvals" and "Rejections" or "Ayes" and "Nays". Some variation of this

3. The front-end is starting to move through a redesign with inspiration from New Design Implementation: Phase 1 #451. /home and /mempool pages have iterated, so any efforts towards trying to find a common style would be good. If not, that's okay too. @gozart1 and I like to pick at that stuff. But at some point, we'll need to stop allowing public pages with the older style.

4. Eventually some kind of filtering will be needed. Are you just sorting by last update right now?

5. Not certain how this would work, but maybe some kind of key or legend that explains what the different phases of the proposal are, i.e. "vetted", "active" etc.

[dmigwi]

Great Notes @buck54321;

• Concerning the new New Design Implementation: Phase 1 #451 inspired theme, I will be modifying some more stuff to get it closer to where is supposed to be.
• The filtering of all proposals is done by the last Update field.
• You just gave me an idea on how to the use space created after adding pagination. This which will create space for the various legends.

[raedah]

Proposal items should likely be imported by oldest first so that the order stays consistent on subsequent syncs.

[chappjc]

I find "onchaindb" and "offchaindb" to be too vague and imprecise (on-chain what?). I'd prefer to see the following packages in the repo folder:

• gov/agendas or gov/deployments - For the various deployment agendas that are directly voted upon with the vote bits in vote transactions.
• gov/proposals or gov/politeia - For the Politeia proposals and the voting that is coordinated by the Politeia server and anchored on the blockchain.

Further, the "offchaindb" package is much more than just a DB. It includes types and a client for communicating with Politeia. These things are useful on their own. Thinking about maximizing the utility and reusability of the code, it's best to split things further (one possibility: gov/politeia/agendadb, gov/politeia/types gov/politeia/piclient.

[chappjc]

Thanks for making those architecture changes! I think it is much more versatile this way.

Just some minor edits requested. Ready to remove WIP?

[dmigwi]

I've some extra minor features to add (proposals pagination and a legend for the various Status and State keywords). Was supposed to be done by now but the corrupt golang installation is messing me up.

[dmigwi]

Latest Change:

• The UI on the two pages "/proposals" and "/proposal/{ID}" has been reorganized.
• Proposal Update is divided into two major sections:
  1. Update for the In progress Proposals - This is update for current proposals with vote statuses PropVoteStatusNotAuthorized, PropVoteStatusAuthorized or PropVoteStatusStarted. All the in new in progress proposals data is updated apart from from proposals whose vote status is still PropVoteStatusNotAuthorized. Happens first always.
  2. Update for new proposals - This is for proposals not yet in the db. It fetches the list of proposals from the Politeia API since the last proposal was updated in the Proposals db.
• Apart from the initial updates check on system start up, proposal db update is run in intervals of 20 blocks when the block chain is not running.

Here are the Modifies UI pages:
Proposals Page:*

Proposal Page:

[buck54321]

Should we add Politeia data endpoints to DCRData API?

We will need to polish the layout. Do you want to work through it here or do it separately?

[chappjc]

@dmigwi Tentatively approved, although needs a rebase/resolve, and a final test on my part.

[chappjc]

(and approval by @buck54321)

[dmigwi]

I am rebasing this PR.

[buck54321]

Just one last thing I'm not certain about.

[dmigwi]

@buck54321 I am not sure of what the said test for :1234 should return. Is :1234 supposed to be a valid url?
If not, I think all is well https://play.golang.org/p/uJdgixbOhsa. I am adding a fix for the first url.

[buck54321]

Expected

retrieveRootPath(localhost:1234/api/) -> localhost:1234
retrieveRootPath(192.168.0.2:1234/api/) -> 192.168.0.2:1234

Actual

retrieveRootPath(localhost:1234/api/) -> localhost:1234/api/
retrieveRootPath(192.168.0.2:1234/api/) -> error

https://play.golang.org/p/JIJbMLCfxLb

[dmigwi]

for retrieveRootPath(localhost:1234/api/) -> localhost:1234/api/ this was fixed by this commit d6f7f1f

for retrieveRootPath(192.168.0.2:1234/api/) -> error
As documented here golang/go#21415 (comment) and here. I don't think making this exception is okay because this error is returned by the official golang's net/url package. Making this exception could come to haunt us later and that is why I think we should not allow it.

[dmigwi]

@buck54321 Here is why trying to reverse this retrieveRootPath(192.168.0.2:1234/api/) -> error is a bug-in-waiting.
https://play.golang.org/p/VTZu41i1nG-

[buck54321]

All addresses need the protocol.

https://play.golang.org/p/DRVTc3efkdb

We certainly want to support connecting by IP:Port, but I suppose adding the protocol is just required then.

[chappjc]

I realized that there's one show-stopper. dcrdata has to work when Politeia is inaccessible. TBH, I think dcrdata should have a no-Politeia option, but we can get to that if needed.

[xaur]

Don't forget to right-align numerical columns :)

[dmigwi]

[dmigwi]

• This add two new pages under /proposals and /propasal/{id} url paths. Proposals listing data is queried from Politeia API endpoints.
• Restructured the agendas listing implementation so that It can be in a shared 'gov' directory with proposal listing implementation.
• Tests for both proposals and agendas listing implementations were added.

[dmigwi]

@chappjc 👆