GitHubStorage: Create LFS config and pointer files

[shevron]

When the lfs_server_url config option is set, we should start creating and committing LFS pointer files and LFS config based on resources we get:

• [x] If lfs_server_url is not set, do not create LFS config / pointer files
• [x] For each resource that is not an external URL, and has sha256 and bytes set, create a suitable LFS pointer file
• [x] If at least one LFS pointer file has to be committed, also create a .gitattributes and .lfsconfig files to match
• [x] Ensure LFS pointer file paths do not conflict and are valid paths (no leading / or /../), otherwise raise ValueError
• [x] Commit all of these in each create / update call

[pdelboca]

In this ticket we discussed how to implement the scenario in which two resources has the same name (possible in CKAN) given that git doesn't allow to filenames with the same name in a folder.

Basically:

• If one resource is named data.csv write a lfspointer called data.csv
• If two/more resources are named data.csv write one lfspointe called data.csv for the first one and <uid>.csv for the second/third/..

[shevron]

We are not going to handle this in metastore-lib, but just expect path values for resources to be set correctly in a non-conflicting way by the calling code.

In the GitHub storage backend, we will do some last minute sanity check on resource paths: before committing them:

• If path is a URL, we do not store a Git LFS pointer and don't need to worry about it
• if path is a POSIX-path and paths conflict, throw ValueError exception
• If path is a POSIX-path and path contains /../ or begins with /, throw ValueError exception

When integrating with CKAN, path normalization and de-duplication will be handled in ckanext-versioning or a conversion library used by it. See https://github.com/datopian/ckanext-versioning/issues/2