Send user-agent string compatible with newer Cisco servers

We need to change the default user-agent string in OpenConnect, at least for the AnyConnect protocol.

Compatibility issue

Some very ancient Cisco servers appear to have required that the client send a User-Agent header which looks like Cisco AnyConnect VPN Agent for Windows 2.2.0133. See bc89952e for evidence suggesting this.

Most (all?) new Cisco servers seem to universally require that the client send a User-Agent header which starts with the exact prefix AnyConnect. See my analysis #544 (comment 1222962472):

• When a client attempts to do XML POST authentication to these servers without a matching User-Agent, they return a 404 Not Found, which is extremely misleading and causes us to fall back to ancient non-XML-POST authentication.
• Non-XML-POST authentication appears to proceed regardless of UA string.
• Most VPN admins only test with recent official clients, so ancient non-XML-POST authentication is typically broken in various confusing ways.
• Because the error message is so poor, and the non-XMLPOST fallback path typically broken in varying ways, it's hard to discover the root cause of the problem. See #544 (closed), #593 (closed), #602 (closed), #618 (closed), #635 (closed), #657 (closed), #662 (closed) for many many different reports of it, not all of which were easily and quickly triaged down to "just use --useragent=AnyConnect".

Basically, we now have tons of confused users who just need --useragent="AnyConnect*" when connecting to Cisco servers, which are by far the most commonly-used protocol. Further, users of front-ends like NetworkManager-OpenConnect get extra frustrated, because they can't easily change the User-Agent header.

Proposed solutions

Change the default

We change the default user-agent string from Open AnyConnect VPN Agent to AnyConnect-compatible OpenConnect VPN Agent.

Pros:

• Should Just Work™ for users of new Cisco servers

Cons:

1. This changes the UA string sent for other protocols too.
2. This may prevent admins of non-Cisco VPNs from keeping accurate stats on how many OpenConnect users they have, if they're checking for our longstanding prefix of Open AnyConnect VPN Agent
3. This might break connectivity to non-Cisco VPNs which specifically whitelist Open AnyConnect VPN Agent as an allowed client prefix.
4. We don't know whether Cisco made this change out of incompetence or malice (#635 (comment 1451782874)), but if it's "malice against OpenConnect" then they'll probably try something else next.

Reasons to do this anyway:

• Playing along with a cat-and-mouse game of incompatibility is annoying, but at least we'll fix things for the large contingent of OpenConnect users connecting to newer Cisco servers.
• Servers that require specific, bespoke UAs will always be fiddly. If there are any VPNs that specifically require OpenConnect's current UA string (Open AnyConnect VPN Agent X.Y.Z), they can continue to specify it manually… if they're using the CLI

Change the default only for protocol=anyconnect

We change the default UA string to AnyConnect-compatible OpenConnect VPN Agent, but only for protocol=anyconnect (compatible with Cisco and ocserv servers).

Pros:

• Should Just Work™ for users of new Cisco servers

Cons:

• This doesn't fit well with the current API, where openconnect_vpninfo_new(), where the UA string is mostly specified when calling openconnect_vpninfo_new, even before the protocol is specified.

Reasons to do this anyway:

• We already have to do ugly UA hacks for other protocols, like GP (see 92e534bd) and Pulse (9779f573)

Fallback

We leave the default alone, but instead of going into ancient non-XML-POST mode if initial XML POST results in 404, we should first try a different UA string, and only then fall back to ancient non-XML-POST mode.

Pros:

• No change to the default UA string

Cons:

• Cisco auth code (auth.c) becomes even more complex and hard to read
• Extra latency from multi-step fallback for the most common case ("connecting to a newish Cisco server with default settings")

Reasons to do this anyway:

• Are there any?