feat(attachments): create context-aware helper for attachments

[Dam-Buty]

Non-Breaking

This creates a new context-aware helper that abstracts the logic around creating attachments, as well as providing the following enhancements :

• Make threadId optional (it is already optional on the API)
• Fix typing to enforce either content or path at compile time
• Accept a variety of formats as input content (ReadableStream, ReadStream, Buffer, File, Blob & ArrayBuffer)
• As a treat i squashed the chainlit-logo to hell so it is <3KB :zap:

Old syntax

// Upload the file
const { objectKey } = await literalClient.api.uploadFile({
  threadId: thread.id,
  content: fileStream,
  mime
});

// Create the Attachment
const attachment = new Attachment({ name: 'Attachment', objectKey, mime });

// Attach it to the step
await thread
  .step({
    name: 'Assistant',
    type: 'assistant_message',
    output: { content: 'Here is the generated image!' },
    attachments: [attachment]
  })
  .send();

New syntax

await literalClient
  .step({
    name: 'Assistant',
    type: 'assistant_message',
    output: { content: 'Here is the generated image!' }
  })
  .wrap(async () => {
    // This will upload the file, create the attachment
    // and automatically attach it to the wrapped step
    await client.api.createAttachment({
      content: fileStream,
      mime,
      name: 'Attachment'
    });
  });

[linear[bot]]

ENG-1590 TS SDK : inconsistencies on uploadFile

The `uploadFile` method on the TS SDK has the following signature : ``` { content?: Maybe; path?: Maybe; id?: Maybe; threadId: string; mime?: Maybe; } ``` * `threadId` is mandatory but it is optional on the API, both in the `upload/file` endpoint & in the Attachment type * `content` on the other hand should be mandatory * `content` is typed `any` but it will definitely break if you don't provide it with a `Readable` For the content part, it is a bit impractical when the file comes from a web form. In this case it is presented to you as a `File` , and it took me a hot minute to figure out that i had to transform it like that : ``` const nodeStream = Readable.fromWeb( formAudio.stream() as ReadableStream ); // nodeStream can now be used in uploadFile ``` In a similar situation, the `openai` SDK provides a `toFile` helper which takes as input a wide variety of `File`, `Blob`, `ArrayBuffer`, `ReadStream` and more, and converts it to something you can upload. As a general rule we want to change the API for attachments, instead of first uploading the file then creating the Attachment instance we should have `client.api.createAttachment` which uploads the file & returns an Attachment instance. `uploadFile` stays as is in case some use cases need it. - [X] Make `threadId` optional - [X] Fix typing to have either `content` or `path` - [X] Accept `ReadableStream`, `ReadStream`, `Buffer`, `File`, `Blob` & `ArrayBuffer` as input content - [X] abstract upload + Attachment instantiation with a helper method `createAttachment`

[Dam-Buty]

I don't think the openai e2e test should be impacted by this change, there are no attachments in those tests.

yes, confirmed, they do work in local