pi: Add proposal statuses.

[amass01]

Plugin model

The plugin model allows for two type of plugins:

• Functionality plugins
• Application plugins

Examples of functionality plugins are the comments plugin and the
ticketvote plugin. These are self contained plugins that are not allowed
to access external state. The comments plugin is only allowed to access
state inside of the comments plugin. This allows these plugins to be
composable. An application that wants to add comments functionality can
do so without having to worry about external dependencies or application
specific behavior that other applications have layered on top.

Application plugins, on the other hand, are allowed to access external
state. These plugins are not composable and are used to extend the
functionality plugins with application specific behavior. Examples of
application plugins include the pi plugin and the cms plugin.

For example, the pi plugin doesn't allow comments on proposals once the
proposal voting period has ended. This is the pi plugin accessing state
in both the comments plugin and the ticketvote plugin in order to create
behavior that is specific to the decred proposal system application.

Each application (pi, cms) should only have one application plugin. A
single plugin to rule all other plugins, so to speak.

A unified proposal status

This commit adds in a proposal status type to the pi plugin that is used
to combine record metadata with other plugin metadata in order to create
a unified proposal status that maps out all possible paths a proposal
can take.

Throughout its life cycle a proposal will accumulate metadata from
different plugins. This metadata determines the status of the proposal.
Listed below are a few examples.

record metadata: record status changes (public, abandoned, etc)
ticketvote metadata: vote status changes (authorized, voting, etc)
pi metadata: billing status changes (active, completed, closed)

There's also an interplay between the different plugin metadata. For
example, the billing status of a proposal can only be updated if the
proposal has been approved in a dcr ticket vote, i.e. the pi plugin
relies on state in the ticketvote plugin.

This creates a lot of complexity that is currently being pushed into the
client. The client must retrieve all of this various metadata and use it
to determine how the proposal should be displayed and whether certain
actions are allowed.

This commit adds a proposal status type to the pi plugin in order to
move this complexity from the client into the pi plugin. The proposal
status is determined at runtime by the pi plugin based on the various
record and plugin metadata that a proposal contains. The proposal status
maps out all possible paths a proposal can take throughout its lifecycle
and serves as the source of truth for how plugin metadata should impact
a proposal.

Having a unified proposal status that can be queried also reduces the
load on the server. Before, the client would need to send 3 separate
requests to the record and plugin APIs in order to ascertain the status
of a proposal. The number of requests will only grow as additional
functionality is added. Having the pi plugin serve as the source of
truth for the proposal status allows the client to retrieve all of this
information using only a single request.

Implementation

- Adds a proposal status type that maps out all of the possible
  paths a proposal can take. This proposal status is determined at
  runtime by the pi plugin based off of the various record and
  plugin metadata. 

- Adds API to the pi plugin that allows the client to retrieve the
  status of a proposal.

- Adds a new pictl command `proposalsummaries "tokens..."` to call
  the new pi API batched route `/summaries`.
  
- Adds `summariespagesize` to the pi API policy call reply.

---

Closes #1471.

[lukebp]

Also needs a pictl command.

[lukebp]

1. The page size should be added to the PolicyReply.
2. Some proposal statuses require a reason to be given (e.g. censored, closed). I think we should probably return the status as well as the reason in the summary. Thoughts?

[lukebp]

decred/politeiagui#2593 is why I think the reason should be added to the proposal summary.

[amass01]

The page size should be added to the PolicyReply.

Done.

[amass01]

Some proposal statuses require a reason to be given (e.g. censored, closed). I think we should probably return the status as well as the reason in the summary. Thoughts?

Done.

[amass01]

@lukebp updated

[lukebp]

I'll give it a final round of testing in the morning, but the code looks good. Should be ready to merge.

[lukebp]

tACK

[lukebp]

Can you replace the This commit completes the "Add proposal lifecycles" item of the 2021 Q3 Pi Proposal. part of your commit message with the following:

Throughout its life cycle a proposal will accumulate metadata from the
various plugins. This metadata determines the status of the proposal.
Listed below are a few examples.

record metadata: record status changes (public, abandoned, etc)
ticketvote metadata: vote status changes (authorized, voting, etc)
pi metadata: billing status changes (active, completed, closed)

There's also an interplay between the different plugin metadata. For
example, the billing status of a proposal can only be updated if the
proposal has been approved in a dcr ticket vote, i.e. the pi plugin
relies on state in the ticketvote plugin.

This creates a lot of complexity that is currently being pushed into the
client. The client must retrieve all of this different metadata from the
backend and use it to determine how the proposal should be displayed and
whether certain actions are allowed.

This commit adds a proposal status type to the pi plugin in order to
move this complexity from the client into the pi plugin. The proposal
status is determined at runtime by the pi plugin based on the various
metadata that a proposal contains. The proposal status maps out all of
the possible paths a proposal can take throughout its lifecycle and
serves as the source of truth for how plugin metadata impacts a
proposal.

Having a unified proposal status that can be queried also reduces the
load on the server. Before, the client would need to send 3 separate
requests to the record and plugin APIs in order to ascertain the status
of a proposal. The number of requests will only grow as additional
functionality is added. Having the pi plugin serve as the source of
truth for the proposal status allows the client to retrieve all of this
information using only a single request.

[amass01]

Can you replace the This commit completes the "Add proposal lifecycles" item of the 2021 Q3 Pi Proposal. part of your commit message with the following:

Throughout its life cycle a proposal will accumulate metadata from the
various plugins. This metadata determines the status of the proposal.
Listed below are a few examples.

record metadata: record status changes (public, abandoned, etc)
ticketvote metadata: vote status changes (authorized, voting, etc)
pi metadata: billing status changes (active, completed, closed)

There's also an interplay between the different plugin metadata. For
example, the billing status of a proposal can only be updated if the
proposal has been approved in a dcr ticket vote, i.e. the pi plugin
relies on state in the ticketvote plugin.

This creates a lot of complexity that is currently being pushed into the
client. The client must retrieve all of this different metadata from the
backend and use it to determine how the proposal should be displayed and
whether certain actions are allowed.

This commit adds a proposal status type to the pi plugin in order to
move this complexity from the client into the pi plugin. The proposal
status is determined at runtime by the pi plugin based on the various
metadata that a proposal contains. The proposal status maps out all of
the possible paths a proposal can take throughout its lifecycle and
serves as the source of truth for how plugin metadata impacts a
proposal.

Having a unified proposal status that can be queried also reduces the
load on the server. Before, the client would need to send 3 separate
requests to the record and plugin APIs in order to ascertain the status
of a proposal. The number of requests will only grow as additional
functionality is added. Having the pi plugin serve as the source of
truth for the proposal status allows the client to retrieve all of this
information using only a single request.

Done.

[marcopeereboom]

This is pretty great. Just one nit.