Offers a solution to issue #361 (Allow Server.observe with authenticated peer)

[ScottErholm]

zetta currently allows for peer link authentication using the hooks server.onPeerRequest, server.onPeerResponse, server.httpServer.onPeerConnect, and server.httpServer.onEventWebsocketConnect. This allows an initiating peer to make a link request to a receiving peer. This assumes that any peer wishing to initiate a connection must know the authorization scheme and credentials required for a particular receiver.

However, things are flipped when the receiving peer wishes to establish a connection back to the initiating peer for a Server.observe. In this situation, it should not be assumed that the receiver knows the authorization scheme and credentials for each and every initiator. Since the receiver doesn't know how to authenticate with the initiator, Server.observe fails for that peer.

This can be alieviated if the initiating peer simply passes the authorization scheme and credentials to the receiver in the response to the receiver's _initiate_peer request. The initiator handles the request in the PeerClient.checkServerReq function, and passes back the authorization in the response header. The receiver in PeerSocket.confirmConnection then keeps track of the authorization if it sees x-authorization-required set in header.

This additional code does not affect processing when peer authentication/authorization is not used. The reverse-authorization passing should work for any authorization scheme. One big assumption is that the initiator scheme and credentials will work in reverse -- that's up to the initiator to fulfill, but if not, then it doesn't fail any worse than it does currently.

[googlebot]

Thanks for your pull request. It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

📝 Please visit https://cla.developers.google.com/ to sign.

Once you've signed, please reply here (e.g. I signed it!) and we'll verify. Thanks.

---

• If you've already signed a CLA, it's possible we don't have your GitHub username or you're using a different email address on your commit. Check your existing CLA data and verify that your email is set on your git commits.
• If your company signed a CLA, they designated a Point of Contact who decides which employees are authorized to participate. You may need to contact the Point of Contact for your company and ask to be added to the group of authorized contributors. If you don't know who your Point of Contact is, direct the project maintainer to go/cla#troubleshoot. The email used to register you as an authorized contributor must be the email used for the Git commit.
• In order to pass this check, please resolve this problem and have the pull request author add another comment and the bot will run again. If the bot doesn't comment, it means it doesn't think anything has changed.

[ScottErholm]

Okay... I signed it

[googlebot]

CLAs look good, thanks!