Consider introducing a browse permission for queues

[michaelklishin]

The permission model in use today is largely specific to one protocol but is flexible enough to support a lot of scenarios.

However, there's one scenario that it does not really cover: "read only" users. The read permission on a queue means several things:

• An ability to inspect queue metrics, etc in the management UI
• An ability to consume messages via messaging protocol clients
• By extension of the above, if the user can consume messages and ack them, they can effective purge the queue, so a queue.purge permission is also granted

For an environment where a "read only user" means "can browse queues and their metrics but has no access to messages", the above model is too permissive.

A new action which we can call browse for now, could only grant the permission to, well, browse the queue and its metrics in the management UI, and not allow any access to the messages in that queue.

Using Prometheus side steps the problem entirely and is the recommended option, but the browse permission may still be worth investigating and not require any significant changes to the permission system as a whole.