feat: Eventing

[james-milligan]

This PR

• adds eventing rpc
• events are emited on successful connection to stream rpc and configuration changes

This PR adds a new rpc to the connect service called EventStream, it accepts an empty proto message google.proto.Empty and returns a stream of message type EventStreamResponse.
EventStreamResponse contains a single string field of type which references an internal notification type used within flagd, such as provider_ready or configuration_change. This rpc will allow for the management of the sdk cache, busting it once a configuration change is detected. It will also allow for the implementation of flag change events once/if the OFEP passes.

[toddbaert]

@AlexsJones just for some background, one of the coolest parts of this is it allows providers to cache resolved flag values (based on a sha of the flag-key and context). The provider can then intelligently bust that cache when the flagd configuration changes because it will get an event indicating such. This significantly reduces traffic and latency, even in server deployments. You can imagine that if user X has already evaluated flag "banner-color" seconds ago, there's no reason to evaluate that again.

[AlexsJones]

@AlexsJones just for some background, one of the coolest parts of this is it allows providers to cache resolved flag values (based on a sha of the flag-key and context). The provider can then intelligently bust that cache when the flagd configuration changes because it will get an event indicating such. This significantly reduces traffic and latency, even in server deployments. You can imagine that if user X has already evaluated flag "banner-color" seconds ago, there's no reason to evaluate that again.

It's a good move, I think the interfaces are getting a bit bruised though - suggesting we encapsulate with a configuration object.