3-Is an endpoint declared this way expecting the request to be coming from an async call,
e.g. an AJAX call from a front-end, or does that declaration merely affect how the execution of that
endpoint is handled on the back-end?
As you guessed, this has no effect on how the client sends the request but if affect the execution and the request handling on the back-end.
2- Are there any major advantages to this declaration over a non-sync implementation?
IE Does this boost performance, scalability, etc...
Sure, let's assume that your server can handle up to 10 requests concurrently, and you have a controller with an action that saves to the database, and that save process takes 5 seconds to finish, in the synchronous case, the thread handles your request is sitting idle for 5 seconds waiting the save process to finish, and that means your server cannot use that thread to process another request, which means if you got 10 concurrent request that is trying to save to the database, your whole server will sit idle waiting these requests to finish which leads to that your server cannot handle any more request, which is very bad in web sites.
The case is different with Async, if your database ORM for example supports async methods, then you can await that method to finish and from the server point of view, the thread processing your request can be freed to process another request which means your server can perform better, and to await your method you need to use async/await supported by C#.
1- What are the major differences between declaring an endpoint this way versus just returning an HttpResponseMessage?
To answer this question, I will recommend you visit this question/answer
Hope this helps.
