GH-36513: [Dev][C#] Add Dependabot configuration for NuGet

[kou]

Rationale for this change

We don't want to adjust PR titles from Dependabot manually.

What changes are included in this PR?

Set the commit message prefix for /csharp/ from Dependabot.

Are these changes tested?

No. I hope that this works well...

Are there any user-facing changes?

No.

• Closes: [Dev][C#] Add Dependabot configuration for NuGet #36513

[github-actions]

⚠️ GitHub issue #36513 has been automatically assigned in GitHub to PR creator.

[assignUser]

+1

[kou]

@eerhardt This causes the following PRs:

• MINOR: [C#] Bump Grpc.AspNetCore.Server from 2.52.0 to 2.55.0 in /csharp #36525
• MINOR: [C#] Bump BenchmarkDotNet from 0.12.1 to 0.13.5 in /csharp #36526
• MINOR: [C#] Bump Grpc.AspNetCore from 2.42.0 to 2.55.0 in /csharp #36527
• MINOR: [C#] Bump Microsoft.NET.Test.Sdk from 15.8.0 to 17.6.3 in /csharp #36528
• MINOR: [C#] Bump BenchmarkDotNet.Diagnostics.Windows from 0.12.1 to 0.13.5 in /csharp #36529
• MINOR: [C#] Bump Microsoft.Bcl.AsyncInterfaces from 6.0.0 to 7.0.0 in /csharp #36530

Are they useful for us? Or should we revert this configuration?

[eerhardt]

Are they useful for us? Or should we revert this configuration?

Some are useful. But some I would suggest not to take. For example #36530.

I would suggest adding this section:

https://github.com/microsoft/semantic-kernel/blob/8d705b30adf0ef94792dacb86424b172b613ffcd/.github/dependabot.yml#L25-L31

For things like System., Microsoft.Bcl., etc. we want to consciously upgrade major versions. There are reasons why customers want to stay on older versions, for example 6.0 which is "LTS - long term support", and not upgrade to 7.0, which goes out of support sooner than 6.0.

See microsoft/semantic-kernel#1799 for reasoning why staying on lower major versions is preferred in some cases.

[kou]

OK. I've opened #36577. Could you review PRs from Dependabot and merge/close them?

[conbench-apache-arrow]

Conbench analyzed the 6 benchmark runs on commit 3cd816c5.

There was 1 benchmark result indicating a performance regression:

• Commit Run on arm64-t4g-linux-compute at 2023-07-07 06:19:14Z
  • params=selectivity_benchmark/batch_size:100000/null_prob:10/bool_true_prob:50/real_time, source=cpp-micro, suite=arrow-acero-filter-benchmark

The full Conbench report has more details.