coverage: 63.704%. remained the same
when pulling b5851c1 on kayrus:new-neutron-quota
into 992e8b7 on gophercloud:main.

To be honest I don't know. Existing support for rbac policies extension already resides in the quota package.

@mandre I think once these new struct members are pointers, it is ok to keep them here. They will be ignored if they're not defined.

I'm not sure either. Let's ask the other maintainers.
@gophercloud/core any opinion on where the quota fields for neutron extensions should live?

Should we add them to openstack/networking/v2/extensions/fwaas_v2 for fwaas quota similar to what we're doing for MTU, or add them directly to openstack/networking/v2/extensions/quotas/ like we've already done for RBAC policy?

I'd be personally in favour of the former, if this is possible, seeing as these are quotas for an extension. Any extension can define its own quota, so this could quickly get out of hand otherwise. My 2c

For context, networing-bgpvpn, neutron-fwaas and networking-sfc all register resource quotas. tap-as-a-service does not.

I shared my thoughts on moving this into a new extension in #3447 (comment). Using pointers for these struct members should be safe and should not introduce issues. Creating separate packages for each individual option, however, could add unnecessary complexity and negatively impact the developer experience for SDK users.