Removing the FIX_ME comment for assert on operator memory.

Due to the plan caching, we might use the same plan again. In that case, operatormem is not 0, to begin with, and it will have previous values. So this assert assumption is wrong and hence removing it. Based on the investigation we found that,

1. Operator Memory is being initialized even if statement_mem get
changed when we use the cached plan.
2. We also confirmed that even though we use plan cache, we will still call the executor init.
3. MemoryAccountId may be another potential candidate in Plan to have a
similar issue. But w.r.t memory account id, we confirmed that is not
serialized from QD to QE and they all get reinitialized anyway when we
do the ExecInit.
Note: We don't serialize memory account id because it is an index to the
account array specific to the current process only.

src/backend/nodes/copyfuncs.c

@@ -197,6 +197,10 @@ CopyPlanFields(Plan *from, Plan *newnode)
 	COPY_SCALAR_FIELD(directDispatch.isDirectDispatch);
 	COPY_NODE_FIELD(directDispatch.contentIds);
 	COPY_SCALAR_FIELD(operatorMemKB);
+	/*
+	 * Don't copy memoryAccountId and this is an index to the account array
+	 * specific to this process only.
+	 */
 }
 
 /*

src/backend/utils/resscheduler/memquota.c

@@ -951,12 +951,6 @@ PolicyEagerFreeAssignWalker(Node *node, PolicyEagerFreeContext *context)
 			 */
 			uint64 memKB = ComputeAvgMemKBForMemIntenseOp(context->groupNode);
 
-			/* GPDB_83_MERGE_FIXME: disabled this assertion. Installcheck-good tripped it.
-			 * I'm not sure why, but nothing too bad happens if we set the memory twice, so
-			 * let's investigate later..
-			 */
-			//Assert(planNode->operatorMemKB == 0);
-
 			planNode->operatorMemKB = memKB;
 
 			OperatorGroupNode *parentGroupNode = GetParentOperatorGroup(context->groupNode);