feat: Add RPO metadata settings

[JesseLovelace]

Adds RPO metadata settings for buckets.

Holding off on adding documentation until this general implementation is approved

See googleapis/google-cloud-java#7700
Fixes: #1106

[ddelgrosso1]

You probably want someone a bit more versed in Java to take a look but to me this is 👍

[frankyn]

Revert this change

[JesseLovelace]

intellij does this automatically and i can't figure out how to turn it off it's infuriating 😭

[frankyn]

https://stackoverflow.com/questions/3348816/intellij-never-use-wildcard-imports

[frankyn]

@BenWhitehead we hit this each time we make a change to a public interface, we've been told it's to protect us from breaking changes, however we are committing breaking changes. It has gone on for years. What are your thoughts on this?

[BenWhitehead]

Clirr is in place to primarily help us know if we are committing a change that breaks binary compatibility. The place it's most beneficial is on our generated code and our "main" apis. In this case, it's less beneficial and unfortunately BucketInfo.Builder is abstract and not annotated with @InternalExtensionOnly which would give us leeway to add methods with no guarantee of binary compatibility for out of project implementations. However, adding this annotation is itself considered a breaking change and would need to be performed at a major version.

Our policy for model classes in general has been that we consider them to generally be safe for adding new methods, unfortunately clirr isn't capable of being made aware that this is a model class and instead requires an entry defined. Unfortunately, at this point, I think we're sort of stuck having to deal with this file until either we reach a new major version when we can annotate this builder and define a general rule or we decide to refactor things and make this class not be abstract and instead simply non-final.

[frankyn]

LGTM unless @BenWhitehead has any additional comments!

[BenWhitehead]

Clirr is in place to primarily help us know if we are committing a change that breaks binary compatibility. The place it's most beneficial is on our generated code and our "main" apis. In this case, it's less beneficial and unfortunately BucketInfo.Builder is abstract and not annotated with @InternalExtensionOnly which would give us leeway to add methods with no guarantee of binary compatibility for out of project implementations. However, adding this annotation is itself considered a breaking change and would need to be performed at a major version.

Our policy for model classes in general has been that we consider them to generally be safe for adding new methods, unfortunately clirr isn't capable of being made aware that this is a model class and instead requires an entry defined. Unfortunately, at this point, I think we're sort of stuck having to deal with this file until either we reach a new major version when we can annotate this builder and define a general rule or we decide to refactor things and make this class not be abstract and instead simply non-final.