Title: Question about promoting RBAC filter API from v2alpha to v2

Description:
The RBAC filter API currently is at v2alpha which means it's considered experimental and has no restrictions on breaking changes according to the Envoy API guidelines, making it less likely for production adoption.

This issues is opened to ask about how can we promote it to v2 to make it stable for more production adoption.

• Option 1: Keep the API as-is and just change the version from v2alpha to v2

• Option 2: Make some improvements when changing from v2alpha to v2. For example,

  • The Permission and Principal could be changed to use the same message considering there're a lot common fields in both of them (e.g. and/or/not/any/header/metadata),
  • The Action could be moved to inside policy so that allow/deny could be used at the same time for precedence policy

Option 1 makes it easier for other people to migrate but it would be harder to make any changes once the API becomes stable.

Option 2 makes some improvements but makes it harder for user to migrate from v2alpha to v2. we need to clarify if the RBAC filter API is being used by users directly and if they are okay for the change of API?

We're wondering how does Envoy generally promote alpha API to stable, and how do you think about the two options for RBAC. Is the RBAC filter API considered a user-facing API and should we optimize this to some extent?
Thank you!

/cc @liminw @wenchenglu @mattklein123 @rodaine @lizan @htuch @rshriram