[Tune] Update generate_id algorithm

[bveeramani]

Signed-off-by: Balaji [email protected]

Why are these changes needed?

tl;dr: uuid1 is based on time, so if you start trials at the same time, their IDs will conflict. See https://discuss.ray.io/t/clashing-trial-ids-run-id-in-wandbloggercallback/8046/3.

Related issue number

Checks

• I've signed off every commit(by using the -s flag, i.e., git commit -s) in this PR.
• I've run scripts/format.sh to lint the changes in this PR.
• I've included any doc changes needed for https://docs.ray.io/en/master/.
• I've made sure the tests are passing. Note that there might be a few flaky tests, see the recent failures at https://flakey-tests.ray.io/
• Testing Strategy
  • Unit tests
  • Release tests
  • This PR is not tested :(

[krfricke]

Should we catch duplicates and regenerate IDs if needed?

[krfricke]

We've just discussed this in person.

Generally, keeping track of a set of unique IDs would be up to the generating function. The two places where we could run into duplicates is on initial trial creation and on Trial.reset() when we start a new trial from a previously errorred trial.

In both cases, tracking existing trial IDs in the experiment scope leads to a lot of added complexity (more so in the first case than in the latter). While we could refactor this, we believe that a switch to uuid4 will be enough: The likelihood that we end up with duplicates here is infinitesimal, and we haven't run into this problem in the past years before. So before we do this, let's see if uuid4 solves our problem.