Merge current and 224 hidden service
------------------------------------

We expect that the current HS system will be around for years after the
deployment of 224 thus they have to co-exists. Both system share common ABI/API
so we want to leverage most of the current system for 224 so we minimize
rewriting code.

"hs_" has been choose for the new namespace of 224. The current system will
keep "rend_" but in certain cases we'll use a base object prefixed with
hs_base_.  We also propose new files to modularize part of the HS subsystem. We
would love to go as far as creating a directory for the HS subsytem, src/or/hs/
but that falls into the "convincing nickm" category :).

The following is a list of objects from the current HS system. It details how
we can use and share current rend_ objects for 224.

List of objects
---------------

* rend_service_t
	./src/or/rendservice.c

	New base object:
		hs_base_service_t
			-> rend_service_t
			-> hs_service_t

	File: hs_service.{c|h}

* rend_cache_store_status_t
	./src/or/rendcache.h
* rend_cache_entry_t
	./src/or/rendcache.h

	New object cache entry: hs_cache_dir_entry_t

	File: hs_cache.{c|h}

	Waiting on special's proposal but in theory with that proposal, we'll only
	have a cache on the IP/HSDir thus using hs_cache_dir_entry_t for the
	directory side and drop the client cache.

	IP/HSDir cache: hs_cache_dir_t

	File: hs_cache.{c|h}

* rend_intro_cell_t
	./src/or/rendservice.h

	New object: hs_intro_cell_t.

	File: hs_cell.{c|h}

* rend_service_add_ephemeral_status_t
	./src/or/rendservice.h

	Nothing changes.

* rend_auth_type_t
	./src/or/or.h

	New object: hs_auth_type_t

	Same as rend_auth_type_t but change enum names to match 224.

	File: hs_common.{c|h}

* rend_service_authorization_t
	./src/or/or.h

	New object: hs_client_auth_t

	Contains the needed client configuration for authorization using a type to
	know which field to get into the union.

	File: hs_client.{c|h}

* rend_data_t
	./src/or/or.h

	New base object:
		hs_base_data_t
			-> rend_data_t
			-> hs_data_t

	File: hs_common.{c|h}

* rend_authorized_client_t
	./src/or/or.h

	New object: hs_service_auth_t

	Contains what you need to do authorization based on the hs_auth_type_t. Use
	a union for the different elements per auth type. That's ONLY service side.

	File: hs_service.{c|h}

* rend_intro_point_t
	./src/or/or.h

	New base object:
		hs_base_intro_point_t
			-> rend_intro_point_t
			-> hs_intro_point_t

	File: hs_common.{c|h}

* rend_service_descriptor_t
	./src/or/or.h

	Note: not point of having "service_" added before because both client and
	service uses the same descriptor thus it should be considered a "HS
	descriptor".

	New base object:
		hs_base_desc_t
			-> rend_service_descriptor_t
			-> hs_desc_t

	File: hs_desc.{c|h}

* rend_encoded_v2_service_descriptor_t
	./src/or/or.h

	New object: hs_desc_encoded_t

	Add a uint8 version so we know what version that object is.

	File: hs_desc.{c|h}

* rend_service_port_config_t
	./src/or/rendservice.h

	Nothing changes. Use is in hs_service_t.

New files (only for 224)
------------------------

* hs_desc.{c|h}

	Handling HS descriptor encoding and parsing. Also for accessors and any
	needed validation function.

* hs_cell.{c|h}

	Handles the new cells that is the parsing, packing, validation and
	accessors.

* hs_service.{c|h}

	Everything that has to do with the service side and handling all
	hs_service_* objects.

* hs_client.{c|h}

	Everything that has to do with the client side and handling all
	hs_client_* objects.

* hs_cache.{c|h}

	Handles the cache on the HSDir side which contains hs_desc_t object.

* hs_common.{c|h}

	Common code and ojects that are shared between client and services.