AOT linker can be smarter about custom attributes

[DoctorKrolic]

Compile this code with NativeAOT and check linker report:

using System.ComponentModel;
using System.Reflection;
using System.Runtime.CompilerServices;

Console.WriteLine(GetDisplayName<MyClass>());

[MethodImpl(MethodImplOptions.NoInlining)]
static string? GetDisplayName<T>()
{
    var attr = typeof(T).GetCustomAttribute<DisplayNameAttribute>();
    return attr?.DisplayName;
}

[DisplayName("Test"), Dummy]
public class MyClass
{
}

public class DummyAttribute : Attribute
{
}

Expected:
DymmyAttribute is not included into the final executable since it is "never" read (I guess GetCustomAttribute<T> enumerates all attributes to find the requested one, but this is an implementation detail and linker can be taught to be smarter about it)

Actual:
DymmyAttribute is included into the final executable

[dotnet-policy-service]

Tagging subscribers to this area: @agocke, @dotnet/ilc-contrib
See info in area-owners.md if you want to be subscribed.

[MichalStrehovsky]

We have code that avoids emitting custom attributes completely if the entire app has no code to read custom attributes. This is easy to audit and we don't have to reason about all the public APIs and internal APIs that could be used to access custom attributes. The payoff we get is worth the low complexity. On the other hand analyzing all the possible ways one could access custom attributes is a lot more complexity and the payoff in real apps is going to be minimal: reflection-using apps are bound to use an API that returns all attributes somewhere in their closure, eliminating any benefit.

I don't think this will ever have a favorable complexity/payoff ratio.