apps: revert the renumbering of enum in pendingop

In PR #1702 we added a new OperationType and ChangeType. However, it
renumbered the enums. In cases where heketi is upgraded when the
db has pending ops, this can lead to undefined behavior.

Signed-off-by: Raghavendra Talur <rtalur@redhat.com>
(cherry picked from commit 9c9c572)

apps/glusterfs/pendingop.go

@@ -28,23 +28,33 @@ import (
 type PendingOperationType int
 
 const (
+	// These values are persisted and we should never change the mapping. Even
+	// if an operation type is deprecated, use a new one and retire the number
+	// associated with it.
+
 	OperationUnknown PendingOperationType = iota
 	OperationCreateVolume
 	OperationDeleteVolume
 	OperationExpandVolume
 	OperationCreateBlockVolume
 	OperationDeleteBlockVolume
-	OperationExpandBlockVolume
 	OperationRemoveDevice
 	OperationCloneVolume
 	OperationBrickEvict
+	OperationExpandBlockVolume
+	// If you have any edit except directly above this line it is probably a
+	// mistake. Read the top comment about renumbering the enums.
 )
 
 // PendingChangeType identifies what kind of lower-level new item or change
 // is being made to the system as part of a higher-level pending operation.
 type PendingChangeType int
 
 const (
+	// These values are persisted and we should never change the mapping. Even
+	// if a change type is deprecated, use a new one and retire the number
+	// associated with it.
+
 	OpUnknown PendingChangeType = iota
 	OpAddBrick
 	OpAddVolume
@@ -53,13 +63,15 @@ const (
 	OpExpandVolume
 	OpAddBlockVolume
 	OpDeleteBlockVolume
-	OpExpandBlockVolume
 	OpRemoveDevice
 	OpCloneVolume
 	OpSnapshotVolume
 	OpAddVolumeClone
 	OpChildOperation
 	OpParentOperation
+	OpExpandBlockVolume
+	// If you have any edit except directly above this line it is probably a
+	// mistake. Read the top comment about renumbering the enums.
 )
 
 // PendingOperationAction tracks individual changes to entries within the