Environment variable related changes

[allenwang28]

This PR does a few things:

Provisioner changes

• This PR originally started to add in VLLM_HOST_IP, world_size and rank as environment variables in proc_mesh creation.
• But then there was a clear need to inherit a few relevant environment variables (like TORCHSTORE_USE_RDMA) in the provisioner, and so I added in:

Environment variable related changes

• Renames env_constants.py to env.py
• Introduces an EnvVar pattern where you can set the name, default value, and description and easily resolve its logical value within code. Reduces boilerplate we had for checking strings etc.
• Applies the changes to the relevant spots in the codebase

[joecummings]

Overall LGTM - huge improvement over our scattered env variables! Just would like to get @felipemello1 's quick thoughts on the perf_tracker stuff.

[joecummings]

Surprising to me that an abstraction like this doesn't exist in the Python world.

[joecummings]

What's the reasoning for caching this?

[felipemello1]

what happens if we do:

all_env_vars()
Some code change an envvar
all_env_vars()

Would we get the first cached or the updated one?

[allenwang28]

hmm, so I assumed that we wouldn't change env vars in the run itself. So to avoid having to create this list every time we create a proc mesh, we cache it

So in your example, we would get the first cached. I think to avoid confusion I'll remove the cache for now...

[joecummings]

I don't exactly follow this - maybe @felipemello1 can weigh in?

[felipemello1]

I wanted a way to shutdown the cuda timing, in case we were worried that it was causing OOM or blocking GPU. Currently it lets you make: everything cpu, everything gpu, keep as it is (none)

we could reduce it to 'make everything cpu', 'keep as it is (none)'

[allenwang28]

yeah I understand why it's implemented this way -- I don't think we need to change it now

[felipemello1]

looks good! I like how we can add descriptions to them :)

Just a small question on the cache portion