Feat: Add user auth

[iFurySt]

The PR will introduce the Basic Auth for OD:

1. Only for auth and no user data saved, because we don't have a DB for now.
2. Use the uid and sid to enhance the session management. we only have the sid for now. so we can manage the sandbox containers like opendev_sandbox_uid_sid. I also think we can consider stopping the container rather than removing it, and the user can resume the previous session without re-init, and regular cleaning of the useless containers (but the memory/agent context needs to be stored and then recalled when resumed).
3. Some guys have the situation to deploy the OD in the same bare machine, this PR can offer the first step to provide one instance to serve multi-users. (There was the problem of container name conflict, fix the issue where session id might be duplicated #1557 add the random str to container name, this is more like the temporary solution)
4. Create a Share-OpenDevin for people to share their interaction trajectories #1802 needs some user info when sharing the interaction trajectories.

[amanape]

What problem are we solving by introducing auth? We don't yet have any persistence to store or secure anything, and we aren't doing anything with their data either.

[neubig]

Yeah, I have a similar question about the necessity for user auth at the moment. Currently we're developing OpenDevin as single-user software that runs locally. We definitely plan on having a hosted demo, but there are a number of ways of doing this, and depending on the method that is used there the strategy for doing auth would be different. My suggestion would be to put this on the backburner for now, and figure it out when we have a better idea of what a multi-tenant system would look like.

[iFurySt]

Okay, if we all believe it's unnecessary at the moment, I can stop working here for now.

[neubig]

That might be best for now, but thanks for the contribution! We should circle back once we have a better idea of what this will look like.