RFC: support pass unique key to Keeper

[Ehco1996]

Hi, first of all thank you for the library!

In the process of trying to use it, we found that because the worker's unique id is achieved through sonyflake, the worker requires an integer between 0 and 255 to achieve the unique id when it is started

fastflow/keeper/keeper.go

Line 14 in 1afa592

func CheckWorkerKey(key string) (int, error) {

In practice, this restriction would lead to reliance on external storage to generate the unique integer in multi-process situations, so I propose that the global unique key can be passed directly from the caller and the keeper component no longer generates the unique key based on number

There are two advantages to this change

• the logic of the keeper component is lighter, no need to generate its own unique keys, no need to introduce sonyflake
• the limit of less than 255 workers is lifted

If you agree to this change, I will provide PR in my free time

thanks

[ShiningRush]

Hi echo, thanks for your proposal, basically I agree with it.
I want declare two points:

1. Worker key limited 0~255 is incorrect, sonyflake is support to use uint16(0~65536) as machine_id, this should be a bug of fastflow
2. using worker key suffix as unique number is very convenient in k8s, because you can deploy your application by stateful set, it can auto generate pod name like stateful-set-0, stateful-set-1 ...

however, support a new way to generate id is LGTM. I think we can decouple id generator:

• if client give a id generator, we could do not check the format of worker key any more
• or else, nothing change