Using only the public key as an identifier for Agents, instead of HTTP subjects

[joepio]

Currently, we use Agent's HTTP subjects as identifiers, instead of their public key.

This approach has some issues:

• Relies on uptime of subject server. The HTTP URL must resolve. That means it becomes unusable when the server goes offline, which is a major dependency.
• Up-front authentication check cost: This fetching mentioned above takes some time, which slows down the first interaction. The next ones will be cached, although...
• Key changes are complicated. If an agent changes their keypair, external stores may have an outdated version, which will (currently) result in errors. We could implement some cache-invalidation logic here, but it's not elegant.

We could instead use the public key (and not the HTTP address) as the primary identifier of Agents:

• Commits and HTTP request will no longer require the Agent's HTTP subject, only the public key
• The signer field will now no longer be an HTTP identifier. To help clients find out information about a Signer, we can create an endpoint for the Server that allows people to find the profile of a user, e.g. /agents?pubkey={key}.
• It might be a good idea to use a did identifier as the subject Further explore DID + Atomic Agent compatibility #59.
• When we reference to agents (e.g. in a Rights array), should we reference by these keys / dids? If that's the case, these keys may become outdated, as keys can rotate. If we use an HTTP identifier which includes the public key (e.g. example.com/agents/{pubkey}, the user can later change their used key by modifying the resource at the mentioned URL. But we re-introduce the original issue: the HTTP identifier may go offline.