Support reducing costs by running nodes in pruned mode

[Jason Dreyzehner]

Currently a production Chaingraph instance requires storage for the Postgres database (~600GB) as well as storage for at least one archival node (~200GB). Depending on your provider, that 200GB of SSD storage is $20 to $40/month.

The archival node is required during initial sync, since Chaingraph needs to request blocks older than 48 hours, but after the sync is complete, it should be possible to scale down total storage requirements by running the node in pruned mode. (Chaingraph will never need to re-request historical blocks, so once Chaingraph has made it to maintenance mode, the node's copy of historical block information is not needed.)

It would be great if the chart made this scale down operation simple – perhaps just a --set nodeName.prune=true which the user can configure after the initial download is complete and the database is being indexed.

Also, it's not trivial to scale down a Kubernetes Persistent Volume in most environments, so we should choose a strategy which is easy for users to handle. Maybe if prune=true, we can print some instructions in NOTES.txt for deleting the now-unused volume, and the cluster will just allocate a new, smaller volume for the pruned node (which will sync again from scratch).

This issue probably depends on the correct handling of pruned nodes in #18.