Improve ILP-over-HTTP Auth

[sappenin]

• Introduce formal Authentication Profiles for ILP-over-HTTP
• Clarify normative auth requirements for ILP-over-HTTP
• Provide recommendations around various best practices relating to performance, security, and operational deployment.

Fundamentally, we need at least one Authentication scheme that all Connectors running ILP-over-HTTP implement, and that scheme should attempt to satisfy the following:

• The scheme should be as simple as possible (emphasis: “as possible”. This doesn’t mean “simplicity over security”. Instead, it means there’s a tradeoff, and we want to find the right balance).
• The scheme should be required for all Connectors to implement in order to encourage broad deployment.
• The scheme should consider high-performance (to support high packet throughput).
• The scheme should resist replays (emphasis: resist, not necessarily be replay-proof, in order to aid in high-performance if required).
• The scheme should not negate or prevent the ability of operators to layer-on more security on top of it, depending on the requirements and characteristics of any given deployment.

Signed-off-by: sappenin sappenin@gmail.com

[sappenin]

Closing this in-favor of https://github.com/interledger/rfcs/pull/559.

Rather than mandating an auth mechanism as part of this RFC, #559 instead pitches the auth profiles as options instead of something normative so that any two peers can work out whatever auth they prefer, with the recs in #559 as a good starting point.