Revamp lotus release process to account for patch release

[shrenujbansal]

User Story

Occasionally, we will come up with important fixes which we need the community to adopt quickly to improve network security and health. With our existing release process, we'd either have to wait for the next impending release to ship the patch, delay an existing inflight release, or submit an adhoc patch release labelled with an increased patch number
The last is what we mostly end up doing. This proposal needs to formalize such a process and answer any questions coming up as a result

Deliverables

The proposal needs to consider and answer the below open questions:

• Contents of the patch release
• Methods to communicate that there's a new patch release
• Identify and distinguish the patch release from a feature release (This could mean revamping the versioning scheme we use today or encoding this information elsewhere)
• Define the required testing bar for patch releases
• Define our policy on updating internal infra to the new patch release
• Decision making approach to ask our integration partners to upgrade to this patch

[rjan90]

Release flow has been documented here: https://github.com/filecoin-project/lotus/blob/master/LOTUS_RELEASE_FLOW.md#lotus-release-flow-, and patch releases here: https://github.com/filecoin-project/lotus/blob/master/LOTUS_RELEASE_FLOW.md#patch-releases