This is a great question which really isn’t explained well in most texts about C# and async.
I searched for this for ages thinking I could and should maybe be implementing my own async I/O methods. If a method/library I was using didn’t have async methods I thought I should somehow wrap these functions in code that made them asynchronous. It turns out that this isn’t really feasible for most programmers. Yes, you can spawn a new thread using Thread.Start(() => {...}) and that does make your code asynchronous, but it also creates a new thread which is an expensive overhead for asynchronous operations. It can certainly free up your UI thread to ensure your app stays responsive, but it doesn’t create a truly async operation the way that HttpClient.GetAsync() is a truly asynchronous operation.
This is because async methods in the .net libraries use something called “standard P/Invoke asynchronous I/O system in .NET” to call low level OS code that doesn’t require a dedicated CPU thread while doing outbound IO (networking or storage). It actually doesn’t dedicate a thread to its work and signals the .net runtime when it’s done doing its stuff.
I’m not familiar with the details but this knowledge is enough to free me from trying to implement async I/O and make me focus on using the async methods already present in the .net libraries (such as HttpClient.GetAsync()). More interesting info can be found here (Microsoft async deep dive) and a nice description by Stephen Cleary here