gpg: Make use of the included key block in a signature.

* g10/import.c (read_key_from_file): Rename to ...
(read_key_from_file_or_buffer): this and add new parameters.  Adjust
callers.
(import_included_key_block): New.
* g10/packet.h (PKT_signature): Add field flags.key_block.
* g10/parse-packet.c (parse_signature): Set that flags.
* g10/sig-check.c (check_signature2): Add parm forced_pk and change
all callers.
* g10/mainproc.c (do_check_sig): Ditto.
(check_sig_and_print): Try the included key block if no key is
available.
--

This is is the second part to support the new Key Block subpacket.
The idea is that after having received a signed mail, it is instantly
possible to reply encrypted - without the need for any centralized
infrastructure.

There is one case where this does not work: A signed mail is received
using a specified signer ID (e.g. using gpg --sender option) and the
key block with only that user ID is thus imported.  The next time a
mail is received using the same key but with a different user ID; the
signatures checks out using the key imported the last time.  However,
the new user id is not imported.  Now when trying to reply to that
last mail, no key will be found.  We need to see whether we can update
a key in such a case.

GnuPG-bug-id: 4856
Signed-off-by: Werner Koch <wk@gnupg.org>

Backported from master

Signed-off-by: Werner Koch <wk@gnupg.org>

g10/pkclist.c

@@ -548,7 +548,7 @@ check_signatures_trust (ctrl_t ctrl, PKT_signature *sig)
   unsigned int trustlevel = TRUST_UNKNOWN;
   int rc=0;
 
-  rc = get_pubkey_for_sig (ctrl, pk, sig);
+  rc = get_pubkey_for_sig (ctrl, pk, sig, NULL);
   if (rc)
     { /* this should not happen */
       log_error("Ooops; the key vanished  - can't check the trust\n");