feat: update schema, add provider key + transform

[luwes]

• this pr updates the asset schema to the schema below.
• poster and sources are derived data so I didn't add them to the stored state yet.
  to generate this derived data, transformer's were added alongside the provider files.
  not in the same file as the provider, because the front-end needs to pull this in.
• I tried to add some more logic to assets.ts and re-use it where was possible.

export interface Asset {
  status: 'sourced' | 'pending' | 'uploading' | 'processing' | 'ready' | 'error';
  originalFilePath: string;
  provider: string;
  providerSpecific?: {
    [provider: string]: { [key: string]: any }
  };
  blurDataURL?: string;
  poster?: string;
  sources?: AssetSource[];
  size?: number;
  error?: any;
  createdAt: number;
  updatedAt: number;

  // Here for backwards compatibility with older assets.
  externalIds?: {
    [key: string]: string; // { uploadId, playbackId, assetId }
  };
}

[mmcc]

This looks good to me! My only thought: do we need/want the CLI to migrate existing assets over? Even if it's not a big deal now, do we want to set the precedent that we'll do so?

[luwes]

do we need/want the CLI to migrate existing assets over? Even if it's not a big deal now, do we want to set the precedent that we'll do so?

it crossed my mind as well, I thought to keep it for the v1.
externalId's is used only in the transformers as a fallback so it's pretty minimal code to stay backwards compatible

[heff]

Looks good to me 👍 (without fully running and testing it)

[heff]

If we get up to 10+ providers is there gonna be any value int splitting them out into their own packages rather than baked in? Or should we always just bake them in since there's a finite amount, to keep our lives easier? No change needed here, just wondering.

[luwes]

that's a good point, we might have to split them up eventually because of the added dependencies that they bring.

[heff]

I think I want to keep pushing on the idea of transforming the asset before it reaches <Video>. import awesomeVideo could include functions for getting dynamic URLs etc, not just metadata. Then I think the next-video UI layer becomes fully optional and you could just do <video src="${awesomeVideo.src}">. But I know the crux of that is remote URLs, so a bigger conversation.