phosphor-certificate-manager refactoring.

[Kurzynski, Zbigniew]

Hi everyone,  
I think it is good time to do some code refactoring in phosphor-certificate-manager.
The certificate manager supports few certificate types, each is managed by a separate service instance.
	phosphor-certificate-manager at authority.service, phosphor-certificate-manager at bmcweb.service, phosphor-certificate-manager at nslcd.service
Initially the certificate manager was designed to support single certificate file. But now one of its instances supports multiple files and the code for that case differs quite much from the rest.
I would like to propose a small refactoring of this code in following steps:

Step 1.
Create a new subclass of Certificate. The base class will remain as is, focusing on single certificate approach, while its derived child will extend it with support for multiple certificates.
The Manager class seems quite generic and I would leave it as is. Two instances will operate on the base Certificate class, while the third will use class derived from the Certificate.

Step 2.
Moving files:
	1. meta-phosphor/recipes-phosphor/certificate/phosphor-nslcd-cert-config/env
	2. meta-phosphor/recipes-phosphor/certificate/phosphor-nslcd-authority-cert-config/env
	3. meta-phosphor/recipes-phosphor/certificate/phosphor-bmcweb-cert-config/env
to repository phosphor-certificate-manager under a new directory 'service'

Getting rid of below recipes and moving their functionality to phosphor-certificate-manager_git.bb if possible.
	phosphor-bmcweb-cert-config.bb, phosphor-nslcd-cert-config.bb, phosphor-nslcd-authority-cert-config.bb

Step 3.
Changing the way of managing and storing TrustStore certificates.

Now all certificates are stored and managed directly in a /etc/ssl/certs/authority/ , but files in that directory are subject to many restrictions like: 
	the files must be named using the subject name's hash and an extension of '.0',
	If there are two files with the same hash they should have different extension number,
	Extension numbers cannot have gaps, which is a problem when we delete some certificates.

I propose to store certificate files in a separate location, where file names do not have such restrictions.
And put in this folder /etc/ssl/certs/authority/ only soft links to original files.
Each time when any of certificate will be changed/deleted/added the manager should simply delete all links from /etc/ssl/certs/authority and the recreate them by iterating all certs files.

Please let me know if you have any concerns.

-Zbigniew
--------------------------------------------------------------------

Intel Technology Poland sp. z o.o.
ul. Slowackiego 173 | 80-298 Gdansk | Sad Rejonowy Gdansk Polnoc | VII Wydzial Gospodarczy Krajowego Rejestru Sadowego - KRS 101882 | NIP 957-07-52-316 | Kapital zakladowy 200.000 PLN.

Ta wiadomosc wraz z zalacznikami jest przeznaczona dla okreslonego adresata i moze zawierac informacje poufne. W razie przypadkowego otrzymania tej wiadomosci, prosimy o powiadomienie nadawcy oraz trwale jej usuniecie; jakiekolwiek
przegladanie lub rozpowszechnianie jest zabronione.
This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). If you are not the intended recipient, please contact the sender and delete all copies; any review or distribution by
others is strictly prohibited.