Review usage of the executor_id

[hzxa21]

executor_id is constructed via actor_id << 32 | operator_id. There are 2 indications:

1. executor_id is unique within each RW cluster. However, it is not necessarily unique across different RW clusters.
2. After refactor: use in-memory actor info for meta operations #23528, it is possible that the same actor id can assign to different jobs after cluster recovery/restart. This means executor_id is not unique across cluster recovery/restart.

We need to review the usage of executor_id and make sure we use it correctly. For example, in starrocks sink, we are using rw-txn-{executor_id}-{ts} as the txn id, which means if there are two RW cluster sinking data to the same SR cluster, even they sink to different target table, the txn id can conflict with each other. This looks risky to me.

Also, we are using executor_id in many sinks including file, monogodb, redshift, snowflake, starrrocks, mqtt sinks. We should also review the usage outside of sink in other components as well.

[hzxa21]

@shanicky @wcy-fdu @xxhZs @wenym1

[wcy-fdu]

IIRC, file sink with(sink_decouple = false) using executor_id as part of the output file name, but currently sink_decouple is by default enabled. I will take a look to double confirm.

[wcy-fdu]

IIRC, file sink with(sink_decouple = false) using executor_id as part of the output file name, but currently sink_decouple is by default enabled. I will take a look to double confirm.

I remembered it wrong. Regardless of whether it's decoupled or not, it always includes executor_id...

[hzxa21]

@xxhZs reminder to review the usage of executor_id in various sinks.