[csharp][netcore-httpclient] Refactor of constructors

[lucamazzanti]

It tries to reduce the number of constructors introduced in previous PR.
Related to: #9060, #9085

Refactor on constructors

In the previous PM I created too much constructors.
This is an emprovement to reduce them:

1. I kept the HttpClient service as first parameter when available in signature
2. Then the configurations
3. Then the optional HttpClientHandler

With this PM we have in ApliClient:

1. ctor()
2. ctor(string basePath)
3. ctor(HttpClient client, HttpClientHandler handler = null)
4. ctor(HttpClient client, string basePath, HttpClientHandler handler = null)

(point 1-2 marked as obsolete)
and in ApiClass:

1. ctor()
2. ctor(string basePath)
3. ctor(Configuration configuration)
4. ctor(HttpClient client, HttpClientHandler handler = null)
5. ctor(HttpClient client, string basePath, HttpClientHandler handler = null)
6. ctor(HttpClient client, Configuration configuration, HttpClientHandler handler = null)
7. ctor(ISynchronousClient client, IAsynchronousClient asyncClient, IReadableConfiguration configuration)

(point 1-3 marked as obsolete)

Obsolete constructors

Marked constructors without the explicit HttpClient parameter as obsolete.

Spaces and indentations

Unfortunatly I had a different setup for spaces and indentations on my IDE and I did not see it on my local versioning tool.
So the changes have some spaces because I fixed my previous PM, moving some tabs to 4 spaces.
They are a few lines not so much, but this is why you see some noise in the diffs, its a fix to keep and I will avoid it at all in the future.

PR checklist

• Read the contribution guidelines.
• Pull Request title clearly describes the work in the pull request and Pull Request description provides details about how to validate the work. Missing information here may result in delayed response from the community.
• Run the following to build the project and update samples:

  ./mvnw clean package 
  ./bin/generate-samples.sh
  ./bin/utils/export_docs_generators.sh
  

  Commit all changed files.
  This is important, as CI jobs will verify all generator outputs of your HEAD commit as it would merge with master.
  These must match the expectations made by your contribution.
  You may regenerate an individual generator by passing the relevant config(s) as an argument to the script, for example ./bin/generate-samples.sh bin/configs/java*.
  For Windows users, please run the script in Git BASH.
• File the PR against the correct branch: master, 5.1.x, 6.0.x
• If your PR is targeting a particular programming language, @mention the technical committee members, so they are more likely to review the pull request.

@mandrean (2017/08) @frankyjuang (2019/09) @shibayan (2020/02) @Blackclaws (2021/03)

[auto-labeler]

👍 Thanks for opening this issue!
🏷 I have applied any labels matching special text in your issue.

The team will review the labels and make any necessary changes.

[wing328]

Minor suggestions: better indentation in the documentation comments and use 4-space instead of tabs

[Blackclaws]

Mark the constructors without HttpClient as obsolete already. I think we all agree that they should not be used except as a compatibility fallback. Aside from that it looks good

[lucamazzanti]

Ok, give me a feedback on the message if it fits, i will change it as you prefer

[Blackclaws]

I would change the Message to: Constructors without HttpClient have non-trivial drawbacks and are thus considered deprecated. Check README.md for details Aside from that LGTM

[lucamazzanti]

I will change the message to "Constructors without HttpClient have non-trivial drawbacks and are thus considered deprecated. Check README.md for details." asap.

[lucamazzanti]

If you have time to review it and merge it, it's all done.

[Blackclaws]

LGTM

[wing328]

Marked constructors without the explicit HttpClient parameter as obsolete.

I have a different opinion on this. Will submit a PR with a use case to start the discussion later (before 5.1.1 release)

Will merge this one to keep the ball rolling.

[wing328]

I ran out of time to submit a PR. Here is what I would suggest:

Do NOT mark constructors (e.g. PetApi()) without the explicit HttpClient parameter as obsolete.

The reason is to cater simple use cases. Consider that the situation in which I want to make a simply call (e.g. GetPetById) to the API server and get something back. All I need is a simple call to get some objects (e.g. Pet) from the server and I only need to make the call once. Performance is not a concern/requirement in the use case.

The goal is to make the auto-generated C# SDK easy-to-use.

What do you guys think?

[lucamazzanti]

If you want to go in the milestone without the obsolete marker and postpone the brainstorm further I will remove the attributes in a few hour.

They were put after the discussion on slack/here to emprove the usate, I think in a .net core application you will embrace the bootstrap and DI so the httpClient is the proper way to go.

Said that, for sure in a smaller project the easier constructor Is preferred. So maybe an obsolete attribute is too much, it is enough to have the new constructors and the readme.

Let me know if i can help you to reach the needs in time.

[wing328]

Yes, please file a PR hwen you've time.

[lucamazzanti]

Done in PR #9373.