introduce a feature to disable/enable to contain a node-id in LogId

[drmingdrmer]

          > Alternatively, looking at the code again, it seems like `Entry` could use a simpler `LogId` only containing `term` and `index`, without the `node_id`. The `node_id` seems to be only relevant for replication reply, where it can be easily computed based on the last `voted_for` for `Matching`. For `Conflict`, it can be ignored, since it's not used. Of course, the default implementation of `RaftLogReader` would be more complex/impossible and quite a few changes would be needed elsewhere...

LogId is also used on a follower to determine if a log entry is identical to the follower's local log entry at the same index, when a follower receives append-entries request.

I have a LogIdList structure that contains every log id from which a new LeaderId starts:
https://github.com/datafuselabs/openraft/blob/main/openraft/src/engine/log_id_list.rs

In fact, in my opinion, such a structure reflects more precisely the data structure in raft.
Logs should be a 2 dimension list entry = logs[leader_id][index].

May be I can introduce a feature to disable/enable to contain a node-id in LogId. 🤔

I'll probably go with the above mentioned storage optimization in the log ("switch" entries) or we'll store our 16B node IDs for each log entry anyway.

I did not know you have such a big node-id :(
Is it possible using a u32 node-id and store the 16B real id in a Node?
Membership stores every NodeId and Node for applications:
https://github.com/datafuselabs/openraft/blob/e31b0f9c8601a995b69c5b8200f62af286e588bb/openraft/src/membership/membership.rs#L73-L87

Originally posted by @drmingdrmer in #652 (comment)

[github-actions]

👋 Thanks for opening this issue!

Get help or engage by:

• /help : to print help messages.
• /assignme : to assign this issue to you.