feat: Add ByteStream resolved_mime_type property

[vblagoje]

Why:

Enhance the MIME type resolution process for the ByteStream data class. It introduces a more flexible and priority-based approach to determine the MIME type of a ByteStream, crucial for handling data from diverse sources with varying MIME type declarations.

• fixes FileTypeRouter should get mime type from ByteStream mime type attribute instead of `meta #7633

What:

• Introduce new feature (see diff) without breaking any existing clients

How can it be used:

• MIME Type Resolution Flexibility: Users can now specify a custom priority for MIME type resolution when creating a ByteStream instance. This is particularly useful for applications that process both local files and streams of data fetched from the web
• Enhanced Data Processing: With the improved MIME type resolution, applications can more accurately and easily determine the type of the data they are processing regardless of the origin of ByteStream (local, web resource etc etc)

How did you test it:

• Unit Testing: Tests were added to verify the correct resolution of MIME types based on various prioritization scenarios, including cases with and without explicitly set MIME types and metadata.
• No regressions were found

Notes for the reviewer:

• NA

[coveralls]

Pull Request Test Coverage Report for Build 9003061415

Warning: This coverage report may be inaccurate.

This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.

• For more information on this, see Tracking coverage changes with pull request builds.
• To avoid this issue with future PRs, see these Recommended CI Configurations.
• For a quick fix, rebase this PR at GitHub. Your next report should be accurate.

Details

• 0 of 0 changed or added relevant lines in 0 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage increased (+0.01%) to 90.344%

---

Totals
Change from base Build 8989574784:	0.01%
Covered Lines:	6521
Relevant Lines:	7218

---

💛 - Coveralls

[masci]

Not sure why we made this PR bigger than needed? I wouldn't rely on objects' meta, let's just fix the expected behaviour

[masci]

I think the only change should be

Suggested change

	mime_type = source.resolved_mime_type
	mime_type = source.mime_type

[vblagoje]

Hey @masci @wochinge and I went back and forth on this one in the background for several rounds before deciding on this approach.

We can't employ this simple solution without breaking some existing components i.e. ContentFetcher that uses metadata of the bytestream to set content_type. We have diversion between local files that set mime_type directly and web based fetches that set content type. And now this property resolves the mime_type regardless of where the data comes from. That's the idea.

[masci]

It's not really breaking, it's more that those components are bugged no? I think by supporting the buggy behaviour we pile up tech debt and make the code more complex, is it really worth it?

[vblagoje]

Yeah, i can do that as well. We can find all the references of content_type and replace it, in one PR. Wdyt @wochinge ?

[vblagoje]

Yeah this will work, we have to change a few things in various tests, in link content fetcher but the change won't have widespread impact on users. Thanks @masci

[wochinge]

Agree that just relying on .mime_type seems simpler - hard for me to overlook the requirements of these other components though so I don't think i'm a good judge here

[vblagoje]

Dropping in favour of #7681