fix: exclude etag from field_behavior lints

[noahdietz]

The etag field should be excluded from the AIP-203 rules, because it is not supposed to be given any behavior annotations per AIP-154.

Fixes #977.

In a separate PR perhaps we should add a rule to enforce that etag should not have any field_behavior annotations at all.

[shwoodard]

I think I would rather have a const etagFieldName = "etag" and have all of the !excludeFields.Contains(f.GetName()) just be f.GetName() != etagFieldName rather than having a stringset with one value, imho.

[noahdietz]

I think I would rather have a const etagFieldName = "etag" and have all of the !excludeFields.Contains(f.GetName()) just be f.GetName() != etagFieldName rather than having a stringset with one value, imho.

I don't have another example of another standard field, but I can imagine there might be others, which is why I started with stringset. For example, I could see string name on the Resource being excluded from all of these. Just easier to expand later. Still want it changed?

[shwoodard]

I don't have another example of another standard field, but I can imagine there might be others, which is why I started with stringset. For example, I could see string name on the Resource being excluded from all of these. Just easier to expand later. Still want it changed?

Ack. Agreed. Can we change the variable name to standardFields?

[noahdietz]

Ack. Agreed. Can we change the variable name to standardFields?

Done!

[GregFurmanek]

I am not sold on the standardFields name. It doesn't seem to describe the intended usage.

[shwoodard]

I am not sold on the standardFields name. It doesn't seem to describe the intended usage.

The variable name for a thing should say what it is and the behavior or how it is used should be demonstrated by the code, in this case, !....Contains(...)

[noahdietz]

I'm going to merge this. The variable name can be discussed here and updated in another PR if necessary.

[GregFurmanek]

@shwoodard So we have named it standardFields? What are standard fields?
I think this use case is quite specific: Fields excluded from evaluation for specific rules.

"StandardFields" gives the reader no indication what this variable is going to be used for,
neither does !...Contains(...) for that matter.

I think making someone read the implementation to figure out what a variable is used for is
not vary kind way to write code.