Subscription: adapt pipe completion signal for automatically drop subscription

[VGalaxies]

• Add topic parameter mode
  • query
  • subscribe
• When to commit PipeTerminateEvent
  • After the DN-side subscription sink receives the PipeTerminateEvent, it reduces the reference count and commits directly, marking the corresponding pipe task as complete.
• How to notify the client
  • When the pipe is automatically dropped and the prefetching queue is unbound, the corresponding prefetching queue is marked as complete (unbind).
  • When the client pulls from a prefetching queue marked as complete, it will get an event containing a TerminationPayload. The client will automatically unsubscribe from the topic of this event.
• How to release resources
  • Upon all associated consumers unsubscribing from the associated topic, reclaim the corresponding prefetching queue (remove).
  • Until all consumers unsubscribe from that topic, all prefetching queues on all DN remain.

---

Example: org.apache.iotdb.SubscriptionSessionExample#dataSubscription3, org.apache.iotdb.SubscriptionSessionExample#dataSubscription4

[Caideyipi]

Note that since the pipe is automatically dropped, the "DropPipeProcedure"s in "DropSubscriptionProcedure" will encounter failure in validation... Need to add some checks or else the procedure will fail.

[VGalaxies]

In DropPipeProcedureV2, no exception will be occurred even if the pipe does not exist...

[Caideyipi]

Okay, checked that there are not.... However there will be a warn log in PipeDataNodeRemainingEventAndTimeMetrics#deregister. Can you remove it incidentally?

[VGalaxies]

Okay, checked that there are not.... However there will be a warn log in PipeDataNodeRemainingEventAndTimeMetrics#deregister. Can you remove it incidentally?

added a boolean return value to dropPipe...

[Caideyipi]

There are 3 points for the rollback function:

1. Usually when we do rollback, we roll back from the last executed to the first executed.
2. We do not rollback DataNode and ConfigNode execution of dropping pipe.
3. Whether the drop subscription procedure needs to be rolled back may need to be considered twice.

[VGalaxies]

Usually when we do rollback, we roll back from the last executed to the first executed.

The DropSubscriptionProcedure has been appropriately modified. The CreateSubscriptionProcedure will be modified in subsequent metadata restructuring.

Whether the drop subscription procedure needs to be rolled back may need to be considered twice.

Before metadata restructuring, considering that the process of changing the topic meta and consumer group meta involves multiple procedures, there could be failures during execution. Therefore, it is currently necessary to consider rolling back part of the procedure to ensure CN metadata consistency.

In the subsequent metadata restructuring, we will consider mapping the drop subscription procedure to a single procedure. At that time we can consider not performing rollback to prevent the occurrence of create subscription after the rollback of drop subscription.

[Caideyipi]

Consider whether to use it before merge.