Remove userToken from almost all chatbot-api.service.ts methods

[AdamFipke]

UPDATE

Partway through me writing this, I just realised that it's literally only the /ask endpoint that requires ChatTokens now (I sorta forgot we made that change).

So all this issue is is to remove the userToken parameter from all methods inside chatbot-api.service.ts except for askQuestion. I would also go through all uses of all methods and remove any temporary users or temporary ChatTokens being made.

---

Original title: Figure out better way to make ChatTokens for our non-user calls

So for context, all of our chatbot API calls require a token that's used to keep track of chatbot usage for our users (so users don't overuse our chatbot).

However, we have quite a few areas where our HelpMe backend initiates a request to the chatbot as a part of background tasks (a user isn't making the request, and we also ALWAYS need to make sure the request goes through). For example:

• LMS items (announcements, files, assignments, etc.) get synchronized to the chatbot in the background
• Course Cleanup emails need to be able to delete chunks in the background
• Possibly more?

And right now, we don't really have a dedicated "backend" chat token. So, one of the ways that we get around that right now is by temporarily creating dummy users and giving them a chat token. For example:

    const tempUser = await UserModel.create({
      email: 'tempemail@example.com',
    }).save();
    const token = await ChatTokenModel.create({
      user: tempUser,
      token: v4(),
      max_uses: 1,
    }).save();

    const status = await this.uploadDocument( // can be any chatbot-api call
      courseId,
      item,
      token,
      type,
      adapter,
    );

    await ChatTokenModel.remove(token);
    await UserModel.remove(tempUser);

This... kinda sucks. There's probably a few different approaches, none of which take up too much work I think. Ideas:

• Create a permanent ChatToken item that can be used as the backend (uses are always infinite). ChatToken would probably need a new attribute (like isSystem) for querying and then a migration file that generates a new ChatToken with isSystem true (only if one doesn't already exist). It would also be great if there was some enforcement to ensure there is only ever 1 ChatToken entity with isSystem true. Moreover, ChatToken requires a user model. You could choose to break that relationship to make it optional. Another option is creating a new entity specifically for it (maybe)
• Make it so on the chatbot repo, you don't require a ChatToken if the backend instead provides something else (some key of some kind, either stored in a .env or a database item like above).