Support specifying per-log bastion hosts (optional feature)

[rgdd]

So called "per-log bastion hosts" was added a while back in litewitness
(v0.7.0). Since then it's also been tested and used by Sigsum folks.

It would be great to get this functionality supported by the witness network.
The diff looks pretty small, and is optional and (afaict) doesn't affect anyone
in the witness network that doesn't care about per-log bastion hosts.

The sketch for what I'd like to see added is roughly:

• Log definition in log list can optionally specify a line "bastion", where the
  value is the URL to the log's own bastion host.
• Witnesses that have no public endpoint (per-log bastion only) try to connect
  to the specified bastion host, and on success a witness keeps the connection
  open.
• We should probably provide a pointer on how to reconnect if the log has not
  configured the witness, but I'm leaving that detail out for now since it's easier
  to specify and discuss in a concrete MR if you're open to the overall idea.
• (Witnesses that already have an endpoint simply ignore the per-log bastion
  line. And log operators that don't have their own bastion host simply can't
  pick witnesses that are per-log bastion only. Which is unfortunate but OK.)

Per-log bastion should not be confused with 3rd party bastion, which from the
log perspective is just a witness with an endpoint that happens to be proxied by
a 3rd party. I do see the utility in 3rd party bastions, but it's also
unfortunate that there's an extra party in the middle that can be down. It's
also a bit of a configuration hassle to be a 3rd party bastion, since there
needs to be authentication setup between logs <-> 3rd party bastion for it to be
any DoS protection in practise. In contrast, a per-log bastion has this
authentication story built in because the log and the bastion are the same.

Thoughts @AlCutter, @FiloSottile before I (or someone with some help and
pointers from me) file a detailed proposal / MR based on the above?

[niels-moller]

Maybe out of scope for the "witness tables", but I think it's worth noting that a witness that wants to connect to per-log bastions has to publish its client cert pubkey, if that differs from the witness' main cosigning key.

[FiloSottile]

This sounds good, at the witness network level it’s just:

1. An optional metadata key for logs to advertise their bastion endpoint for witnesses that need one. (Other witnesses can ignore it.)
2. Accepting witnesses in the table that have no public submission endpoint and require a bastion. (Logs that don’t want to run a bastion can just avoid selecting these witnesses.)
3. Adding an optional metadata field to witnesses for their bastion mTLS key. (I actually think we should encourage not reusing the witness key.)

@rgdd, can you go ahead with a PR?

[rgdd]

@rgdd, can you go ahead with a PR?

Yes, and thanks for the input and pointers @FiloSottile and @niels-moller.