Adding grid_file_path to recipe metadata for uploads

[rugeli]

Problem

What is the problem this work solves, including
closes #266

Solution

What I/we did to solve this problem

• relocated function: removed get_only_recipe_metadata from recipe_loader.py, and added get_recipe_metadata in upload.py
• modified the function to explicitly check for and extract the grid_file_path if it exists in recipe data

Type of change

Please delete options that are not relevant.

• New feature (non-breaking change which adds functionality)

Steps to Verify:

1. Upload a recipe that includes the grid_file_path to firebase. Run upload -r cellpack/tests/recipes/v2/test_url_load.json
2. Verify that the recipe contains all the expected fields.

Note: At this stage of development, we'll need to delete any existing recipe in firebase before re-uploading a recipe with the same name. Discussions are ongoing about enabling options to overwrite or update existing recipes

[github-actions]

Packing analysis report

Analysis for packing results located at cellpack/tests/outputs/test_spheres/spheresSST

Ingredient name	Encapsulating radius	Average number packed
ext_A	25	236.0

Packing image

Distance analysis

Expected minimum distance: 50.00
Actual minimum distance: 50.01

Ingredient key	Pairwise distance distribution
ext_A

[mogres]

The changes look good! I was able to upload and run the example recipe from firebase.

[mogres]

Q: should we check for all keys in loader.recipe_data and add them to the recipe_meta_data (except composition)? This way we won't have to do a special check for grid_file_path or any new keys we add to the recipe down the line.

[rugeli]

Thank you for asking! I was thinking the same approach: iterating over recipe data and recording every key except for objects, representations, etc., to make the uploading more programmatic. However I went with specified keys(for now) so we get to fully control which keys are displayed and needed in the metadata. Helping to prevent errors during data handling.

And you're right, if there will be more new top-layer keys, we should think about a more dynamic way to manage it.