Consider adding an option to load profiles in CLI using samply's symbolication server #6052

Currently it's possible to do something like:

• Record a profile using samply record --save-only
• Load a profile using profiler-cli

But this doesn't give us the ability to use samply's symbolication server for symbolication and the assembly view. So there is a better way:

• Record a profile using samply record
• Keep its symbol server alive (or alternative would be samply record --save-only + samply load)
• And then while loading the profile in the cli, make sure to include the profile link that includes the symbol server path or pass --symbol-server <url> to the cli.
  • Note: While I was writing this issue I noticed that we actually have a bug here! I filed profiler-cli function annotate command doesn't look at the symbol server in the redux state #6050 and fixing it in Use URL-state symbol server for profiler-cli function annotate #6051.

This works(-ish, due to the bug I mentioned above), but it's not the best UX. Ideally we should reduce the amount of friction of "profiling + analysis" workflows.

There are a few competing ideas to do this:

• Add something like profiler-cli samply record ... which CLI calls samply to record and keeps the server alive until the analysis session is dead.
• Add something like profiler-cli load --with-samply <path>, which does samply load internally. So we can split the samply recording and the analysis parts into two concrete calls with samply record --save-only + cli. During the profile loading, profiler-cli would still hand it over to the samply for loading so it can start the symbol server.
• Add something like --with-profiler-cli to samply record so it loads the profile after recording. But this seems like more effort and probably not the best UX either.

It feels like 1st idea is the best in terms of least friction. But I'm not so sure about passing samply record arguments to samply, it feels a bit messy. On the other hand, I think 2nd is a little more friction compared to 1, but probably less messy.

┆Issue is synchronized with this Jira Task