Ooph, slow_ed25519.py warns that this shouldn't be run in production and
now I see why.

Each blinded key creation and signing takes three seconds, raising our unit
test runtime from 6s to 51s. This complicates working on this branch so
disabling these tests until I can sort this out.

  % ./run_tests.py --unit --test descriptor.hidden_service_v3 --verbose

  ======================================================================
   test.unit.descriptor.hidden_service_v3.TestHiddenServiceDescriptorV3
  ======================================================================

  test_address_from_public_key                           0 ms  [SUCCESS]
  test_decryption                                        3 ms  [SUCCESS]
  test_encode_decode_descriptor                         2.94s  [SUCCESS]
  test_inner_layer                                       0 ms  [SUCCESS]
  test_inner_layer_creation                              3 ms  [SUCCESS]
  test_intro_point_creation                              0 ms  [SUCCESS]
  test_intro_point_crypto                                0 ms  [SUCCESS]
  test_intro_point_crypto_without_prereq                 0 ms  [SUCCESS]
  test_intro_point_encode                                0 ms  [SUCCESS]
  test_intro_point_parse                                 0 ms  [SUCCESS]
  test_invalid_lifetime                                 9.05s  [SUCCESS]
  test_invalid_revision_counter                         9.12s  [SUCCESS]
  test_invalid_version                                  8.98s  [SUCCESS]
  test_outer_layer                                       0 ms  [SUCCESS]
  test_outer_layer_creation                              3 ms  [SUCCESS]
  test_public_key_from_address                           0 ms  [SUCCESS]
  test_real_descriptor                                   1 ms  [SUCCESS]
  test_required_fields                                 18.31s  [SUCCESS]

  ----------------------------------------------------------------------

This might *not* fully fix python3 support, but closer. I don't quite grok why
but my openssl bindings have ed25519 support with python 2.7 but not 3.5. Oh
well, fixing what I can for now.

  % python
  Python 2.7.12 (default, Oct  8 2019, 14:14:10)

  >>> import cryptography
  >>> cryptography.__version__
  '2.7'

  >>> from cryptography.hazmat.backends.openssl.backend import backend
  >>> backend.ed25519_supported()
  True

  ------------------------------------------------------------

  % python3
  Python 3.5.2 (default, Oct  8 2019, 13:06:37)

  >>> import cryptography
  >>> cryptography.__version__
  '2.8'

  >>> from cryptography.hazmat.backends.openssl.backend import backend
  >>> backend.ed25519_supported()
  False

Now that we have all the building blocks in place we can tackle HSv3 descriptor
creation itself. Two main changes are...

  1. More flexibility. All parameters are now customizable.

  2. Simpler. All parameters have defaults so simply calling
     HiddenServiceDescriptorV3.create() once again works.

Flattening the last content() helper so we can see all the remaining
implementation in one spot. Getting close!

Similar approach as the inner layer. This will provide more flexibility once we
propagate the attribute up HiddenServiceDescriptorV3.content().

InnerLayer creation, encryption, and test. While _get_superencrypted_blob()
provided a great demo, it was limited to just introduction points. Now we'll
support anything the layer does.

Maybe I'm missing something, but why not simply pad using the modulus?

We already had a _decrypt_layer() helper from the last branch. While doing the
same for encryption it became evedent that these helpers are mostly identical
so refactoring the common crypto into a third function.

Still not perfectly happy, but closer. :P

I love that test_encode_decode_descriptor() exercises re-parsing a descriptor
we create. Adding a more targeted test to do this only for introduction points.
We can then add companion tests once the InnerLayer and OuterLayer classes have
creation methods.

Moving the subset of ed25519_exts_ref that's used into hsv3_crypto to give
myself one fewer modules to puzzle out.

Now that introduction points can encode themselves there's no value in this
helper.

This class' verify() method was never called, making it effectively a container
for its single attribute.

We convert keys to bytes in enough places that this warrants a helper. Oddly
the HSv3PublicBlindedKey class didn't actually implement its public_bytes()
method so replacing its calls.

Making all the arguments except address/port optional so callers can opt to
skip them.

Adapting a couple checks I disabled earlier.

Our test's _helper_get_intro() provided a good recipie for creating
introduction points. Productionizing this into a helper we can provide
to make these without worrying about too many details.

Oops, missed the 'descriptor' module part of these pydocs.

George adjusted _decrypt_layer() to use his hsv3_crypto module. Swapping this
back to what we had.

We're now at a point where we can drop our prototype introduction point and
certificate classes. Our test_encode_decode_certificate() test is redundant
with test_certificate_encoding().

Adjusting our test_encode_decode_descriptor() test to use our present
IntroductionPoint class rather than the prototype.

Constructing from packed values made construction of a LinkSpecifier a pita.
Taking an address/port argument instead.

Now that we have the building blocks it's a simple matter for us to encode HSv3
introductory points back into strings.

IntroductionPointV3 requires an encode() method, so fitting for the class to
first include its parser.

We retain introduction point ordering so there's no need to iterate over the
original to match.

Standardizing our return type so unit tests pass with python3.

On reflection working with bytes rather than base64 within our child class
makes us more consistent with other parsers. Our parent class can provide
base64 counterparts.

There we go. Now that we parse certificates and extensions like datatypes we
can implement their packing methods.

So much cleaner! Moving unpacking into this class simplifies
Ed25519CertificateV1's from_base64(), and lays the groundwork for packing.

Our stem.client.datatype's packing/unpacking is considerably more readable than
what I implemented here. We need packing support anyway, so modeling unpacking
after the datatype module's pattern.

We already implement its interface, so why not? Functionally subclassing
doesn't provide much (adds unpack() and equality check), but clearly this
should be a Field.

Finally settled on to_base64() and from_base64() methods. Not implemented yet,
just stubbing the API I think we'll want.

Why did I have a 'version' argument? The version is part of the class name - if
it ever *isn't* one that's a problem. ;P

Also, having separate encoded/decoded constructor arguments for the exact same
thing was silly. Decoding base64 twice is cheap, and having two arguments risks
having them mismatch (which would be a frustrating headache to troubleshoot).

Oops, forgot that we have these test requirement annotations.

Simple helpers for cryptographic keys and a few tests. George's test still
passes, but I haven't yet added the encoding support his class has.

I'm unsure exactly how we'd care to constitute our IntroductionPointV3 class.
Likely it will be a hybrid of what we had and the revisions. Simply forking the
class to start with so I can better understand the operative bits of the new
variant.

The test at present passes without a 'ed25519_private_identity_key' argument.
That was not part of what this is testing so reverting to what we had.

Couple helpers are only used in a test. Colocating the helpers there.

Cryptography imports must be localized to where we use it. Otherwise this
completely breaks stem when cryptography is unavilable.